Exception Handling – Preventing System Crashes

On the conventional wisdom that states that you should only throw an exception when a condition occurs that you can't handle in your code we tend to focus on the definition of an exceptional condition but ignore the definition of what it means to handle the exception. A process may encounter a exception communicating with a particular node and may handle the exception by redirecting its request to a backup node instead. However, if a call to create an entry in a table fails because of a unique constraint as a result of a value entered by a user the only entity that can truly handle the condition is the user. Therefore this is grounds for throwing an exception as you cannot handle it in your code.

The semantics of your code also matters. Sticking with the example of creating a new user entry; a call to isAvailableUserName(userName) should not throw an exception if the userName already exists in the database whereas a call to createNewUser(userName) probably should. One reason to throw an exception instead of using a return code is that return codes in themselves provide inadequate information and require a lookup table or an enum that then becomes a dependency magnet. Exceptions on the other hand are more descriptive and contain a message, a backtrace, nested exceptions, etc. Exceptions also make your code cleaner. Instead of having lots of nested ifs that exist solely to test conditions, your code can function the way its supposed to and halt execution when a bad thing happens. Robert C. Martin in his book "Clean Code" states that error handling should not obscure the logic of the code. The cleanliness of the code also applies to the caller as return codes force the callers of the code to have to check for errors immediately after the call. Since this can easily be forgotten or ignored, its not a good approach. However, an exception cannot be ignored but must be handled.

One problem with letting exceptions go past main is that the program will end with a call to std::terminate which default behavior is to call std::abort. It is only implementation defined if stack unwinding is done before calling terminate so your program can end without calling a single destructor! If you have some resource that really needed to be restored by a destructor call, you're in a pickle...