Understanding Class Invariants and Exception Handling

Exception handling is easiest to learn by reading code that uses it. Picture a function that wraps a single operation in a try block and attaches two separate handlers to that block. One handler accepts std::length_error, which describes a negative size, and the other accepts std::bad_alloc, which describes memory exhaustion. Before reading further, try to predict which handler runs for each kind of failure.

Keep one question in mind as you read the rest of this article: at the moment an exception is raised, which handler does control reach, and what happens to the rest of the try block? Answering that question precisely is the skill this article builds. Each example below uses the same idea.

A try block can be followed by several catch blocks, and each one names the type of exception it handles. This is how one function can respond differently to different kinds of failure. The diagram below shows the decision logic in the order the program applies it. If no exception is raised, the try block completes and no handler runs. If an exception is raised, the type of that exception decides which catch block receives it. The matching handler runs, and the other handler is skipped.

Now trace the function step by step. Assume the exception raised is the length error, which the source labels as the negative size case. Control enters the try block and reaches the statement that raises the exception. Execution of the rest of the try block stops at that point. Control then checks the catch clauses in order, finds the one that names std::length_error, and runs that handler. The bad_alloc handler is never entered. Being able to say which handler matched and what happened next is the skill that lets you find where a result diverged from what you expected.

The rule that governs selection is simple. The thrown exception has a type, and the catch clause that names a matching type is the one that receives it. Statements in the try block that come after the throw never run, because the throw transfers control out of the try block. This is the point where execution diverges from the straight-line path a reader might expect. The handler that receives control is chosen by type, not by the order in which you wrote the statements inside the try block.

The example below is an illustrative version written for this article. It follows the structure the source describes, with a try block and two catch clauses named for std::length_error and std::bad_alloc, but it fills the handler bodies with output so that the path is visible. The source's own version leaves the bodies as comments.

The output above follows from the rules. Calling test with a negative value raises a length error, the length_error clause matches, and its handler prints its message. The bad_alloc clause is skipped. Because that handler finishes normally, control continues to the statement after the construct. Calling test with a very large value would instead select the bad_alloc clause and skip the other one.

Sometimes a function catches an exception, does something useful, and then decides the error should continue upward. The source calls this rethrowing. A bare throw statement, one with no operand, placed inside a catch block rethrows the exception that was caught, so that it propagates further. The handler does not stop the error. It performs its own work and then hands the same error onward. The source describes this in a version of test() where the length_error handler prints a message and then executes a bare throw.

The key change is that control does not finish normally after the length_error catch block. The exception leaves the handler and continues on its way. Whether anything further up handles it depends on code outside this function, which the source does not show. The diagram below illustrates that continuation in terms of the call stack.

The standard exception types only tell a handler what category of problem occurred. A custom exception class can describe the situation in more detail. The source states the purpose directly: a custom class can carry arbitrary information from the place where an error is detected to the place where that error can be handled. The class is not just a label. It is a container for whatever details the handler will need. The exception object is a vehicle for information, and its class defines what that information can look like.

The source does not show a full class definition, so the sketch below is a generated illustration of the idea rather than the source's code. It stores a line number and a message at the throw site, and a handler far away can read them back later.

Not every exception should be passed onward or recovered from in the current function. In the second handler of the rethrowing example, the code catches std::bad_alloc and calls std::terminate(). The reasoning in the source is that test() is not designed to handle memory exhaustion. The function has no sensible way to continue, so the code ends the program on purpose instead of pretending the error was handled. The source states that std::terminate() should be used deliberately for this reason.