Don't avoid exceptions

Reason

There seem to be four main reasons given for not using exceptions:

• exceptions are inefficient
• exceptions lead to leaks and errors
• exception performance is not predictable
• the exception-handling run-time support takes up too much space

There is no way we can settle this issue to the satisfaction of everybody. After all, the discussions about exceptions have been going on for 40+ years. Some languages cannot be used without exceptions, but others do not support them. This leads to strong traditions for the use and non-use of exceptions, and to heated debates.

However, we can briefly outline why we consider exceptions the best alternative for general-purpose programming and in the context of these guidelines. Simple arguments for and against are often inconclusive. There are specialized applications where exceptions indeed can be inappropriate (e.g., hard-real-time systems without support for reliable estimates of the cost of handling an exception).

Consider the major objections to exceptions in turn

Compared to what? When comparing make sure that the same set of errors are handled and that they are handled equivalently. In particular, do not compare a program that immediately terminates on seeing an error to a program that carefully cleans up resources before logging an error. Yes, some systems have poor exception handling implementations; sometimes, such implementations force us to use other error-handling approaches, but that's not a fundamental problem with exceptions. When using an efficiency argument - in any context - be careful that you have good data that actually provides insight into the problem under discussion.

They do not. If your program is a rat's nest of pointers without an overall strategy for resource management, you have a problem whatever you do. If your system consists of a million lines of such code, you probably will not be able to use exceptions, but that's a problem with excessive and undisciplined pointer use, rather than with exceptions. In our opinion, you need RAII to make exception-based error handling simple and safe -- simpler and safer than alternatives.

If you are in a hard-real-time system where you must guarantee completion of a task in a given time, you need tools to back up such guarantees. As far as we know such tools are not available (at least not to most programmers).

This can be the case in small (usually embedded) systems. However, before abandoning exceptions consider what space consistent error-handling using error-codes would require and what failure to catch an error would cost.

• Exceptions are inefficient:
• Exceptions lead to leaks and errors.
• Exception performance is not predictable.
• The exception-handling run-time support takes up too much space.

Many, possibly most, problems with exceptions stem from historical needs to interact with messy old code.

The fundamental arguments for the use of exceptions are

• They clearly differentiate between erroneous return and ordinary return
• They cannot be forgotten or ignored
• They can be used systematically

Remember

• Exceptions are for reporting errors (in C++; other languages can have different uses for exceptions).
• Exceptions are not for errors that can be handled locally.
• Don't try to catch every exception in every function (that's tedious, clumsy, and leads to slow code).
• Exceptions are not for errors that require instant termination of a module/system after a non-recoverable error.

Example

???

Alternative

• RAII
• Contracts/assertions: Use GSL's Expects and Ensures (until we get language support for contracts)