Question

I’m having a discussion about which way to go in a new C++ project. I favor exceptions over return codes (for exceptional cases only) for the following reasons –

1. Constructors can’t give a return code
2. Decouples the failure path (which should be very rare) from the logical code which is cleaner
3. Faster in the non-exceptional case (no checking if/else hundreds of thousands of times)
4. If someone screws up the return code settings (forgets to return FAIL) it can take a very long time to track down.
5. Better information from the message contained in the error. (It was pointed out to me that a return enum could do the same for error codes)
6. From Jared Par Impossible to ignore without code to specifically designed to handle it

These are the points I’ve come up with from thinking about it and from google searches. I must admit to being predisposed to exceptions having worked in C# for the past couple of years. Please post further reasons for using exceptions over return codes. For those who prefer return codes, I would also be willing to listen to your reasoning. Thanks

Answer 1

I think this article sums it up.

Arguments for Using Exceptions

1. Exceptions separate error-handling code from the normal program flow and thus make the code more readable, robust and extensible.
2. Throwing an exception is the only clean way to report an error from a constructor.
3. Exceptions are hard to ignore, unlike error codes.
4. Exceptions are easily propagated from deeply nested functions.
5. Exceptions can be, and often are, user defined types that carry much more information than an error code.
6. Exception objects are matched to the handlers by using the type system.

Arguments against Using Exceptions

1. Exceptions break code structure by creating multiple invisible exit points that make code hard to read and inspect.
2. Exceptions easily lead to resource leaks, especially in a language that has no built-in garbage collector and finally blocks.
3. Learning to write exception safe code is hard.
4. Exceptions are expensive and break the promise to pay only for what we use.
5. Exceptions are hard to introduce to legacy code.
6. Exceptions are easily abused for performing tasks that belong to normal program flow.