Exceptions vs Error Codes [LWN.net]

Exceptions vs Error Codes

Posted Mar 30, 2012 19:24 UTC (Fri) by dgm (subscriber, #49227)
In reply to: Exceptions vs Error Codes by khim
Parent article: Go version 1 released

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.

(Log in to post comments)

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.