Exceptions vs Error Codes [LWN.net]

Exceptions vs Error Codes

Posted Mar 30, 2012 16:22 UTC (Fri) by khim (subscriber, #9252)
In reply to: Exceptions vs Error Codes by nybble41
Parent article: Go version 1 released

So there are no "unsuspecting functions"; the only stack frames which an exception will unwind are those which declared that exception in the prototype.

That's why huge amount of Java code includes empty catch statements. And still RuntimeExceptions blow up programs regularly. I'm not sure if it's even possible to sanely use exceptions, but C#/Java exception handling is disaster.

In my experience exceptions are useless in most cases: sometimes you really want to compartmentalize your program, but fork(2) works fine in such cases. If your task is not large enough to use fork(2) then it's probably not large enough to warrant complex exception-based schemes.

(Log in to post comments)

Exceptions vs Error Codes

Posted Mar 30, 2012 19:24 UTC (Fri) by dgm (subscriber, #49227) [Link]

On the other hand, exceptions tend to work nice when you have to repeatedly call library functions that almost always work as intended (that is, errors are really exceptional). In that case you can save a lot of error checking and write simpler code.

Working with exceptions is tricky, but if you know (and follow) the rules it's not more difficult than treads or pointers (:-P)

I will not pretend to know all the rules, but those have served me well:

1. Never, EVER add exceptions to code written without them in mind (this applies basically to C/C++). If you want to use exceptions, do so from day one, or rewrite unaware code.
2. Never, EVER let an uncaught exception escape a callback or event handler. NEVER. And conversely, ALWAYS catch all exceptions when calling back external code or firing events.
3. DON'T use exceptions for common cases or conditions that are easily recoverable. They are best for situations that are truly exceptional and hard to recover from.
4. Program defensively, specially when holding resources (open files, locks, connections, memory). Expect unexpected exceptions everywhere. Your code will probably have a longer and more interesting live than you expect.
5. Handle exceptions ONLY where they make sense. Handling each and every exception everywhere just makes code complex, defeating their purpose. If (when) you find yourself in a mess of try...catches stop and reconsider the exceptions you're using. Do not discard avoiding exceptions altogether.

Ah, just one more thing: don't feed them after midnight. Just don't do it.

Exceptions vs Error Codes

Posted Mar 30, 2012 22:01 UTC (Fri) by khim (subscriber, #9252) [Link]

On the other hand, exceptions tend to work nice when you have to repeatedly call library functions that almost always work as intended (that is, errors are really exceptional). In that case you can save a lot of error checking and write simpler code.

Yup. And as added bonus it'll guarantee your future employment when you'll find and fix dozens of security bugs and DOS cases.

4. Program defensively, specially when holding resources (open files, locks, connections, memory). Expect unexpected exceptions everywhere. Your code will probably have a longer and more interesting live than you expect.

This is what makes exceptions pointless. It's hard enough to find programmers which can correctly programs the common case. Someone who can correctly program all the exceptional codepaths will be usually too expensive. And will still miss some cases.

This is where fork(2) solution saves your beacon: sure, you still need to somehow handle cases where some shared resources (such as pipe or shared memory) misbehaves because other process died but most of the heavy lifting will be done by OS without your direct involvement: sockets will be freed, files will be closed and removed (you do remove temporary files right after open(2) call, because you need to handle poweroff case, right?), etc.

Go is trying to create something like this in a single process - but I'm not 100% sure how well it'll work.

Exceptions vs Error Codes

Posted Mar 30, 2012 23:13 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

>This is what makes exceptions pointless. It's hard enough to find programmers which can correctly programs the common case. Someone who can correctly program all the exceptional codepaths will be usually too expensive. And will still miss some cases.

Nope. It's easy in C++ - just wrap everything in RAII-based holders. If you need a cleanup action then wrap it in ON_SCOPE_EXIT macro or make it a lambda function (C++11 is great!). Pretty easy once you get used to it.

On the other hand, meticulously handling return codes just doesn't happen if you don't force it through code reviews.

Exceptions vs Error Codes

Posted Apr 2, 2012 8:02 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> That's why huge amount of Java code includes empty catch statements. And still RuntimeExceptions blow up programs regularly. I'm not sure if it's even possible to sanely use exceptions, but C#/Java exception handling is disaster.

Nope. The reason for this is huge amounts of lazy and clueless programmers. And Java's exceptions are far from being a disaster. I actually love them, despite some wrinkles. There was a time when I submitted to this "exceptions are evil, declare everything as throwing Throwable" movement and I regretted this ever since. I'm also reminded of this every time I have to code something in C and error handling becomes a chore and pain even worse than manual memory management ;)