Exception Handling Basics

Imagine writing a function that fetches the item stored at a given position in a collection. The caller passes in a position, and the function reads whatever item sits there. Most of the time the caller supplies a sensible number. But suppose the caller asks for position 10 in a collection that holds only three items. Reading that position would mean reading memory that does not belong to the collection, which can produce a wrong answer or a crash. The function has to make a decision about this case, and the decision is what exception handling is for.

Think of a function as an agreement between the code that calls it and the code that implements it. The implementer promises a result, but only when the caller keeps up their end. The conditions the caller must satisfy before the function can do its job are the function's preconditions. Each precondition is a statement the function takes for granted on entry, and the function's work rests on those statements being true.

A precondition is not automatically a bug in the caller's code. It is a boundary that tells the caller which inputs are acceptable. When a precondition is violated, the failure belongs to the caller's request, and the function is right to refuse the request rather than guess at what was meant. For the position lookup, the precondition is that the position must be a valid position in the collection. Stated in the form the source uses, the caller must supply a position that lies in the range from zero up to the size of the collection.

Preconditions about positions are usually written as ranges, and a convenient form is the half-open range $[a, b)$. The square bracket on the left means the start value $a$ belongs to the range. The round parenthesis on the right means the end value $b$ does not belong to the range. Every value from $a$ up to, but not including, $b$ is inside the range.

The half-open style fits positions in a collection especially well. If a collection has $n$ items, its valid positions are $[0, n)$. The lower bound $0$ is the first item, and the upper bound $n$ is excluded because no item sits there. The valid positions are therefore $0, 1, \ldots, n-1$, which is exactly $n$ positions with nothing left over.

A function that has identified its preconditions can check them when it runs. When the argument fails the check, the function should not carry on as if everything were fine. One clean way to report the problem is to signal it with an exception. The function stops its normal work at that point and hands control to whoever is prepared to deal with the failure. Nothing is read from an invalid location, and the caller learns that its request was rejected.

The following function implements the idea directly. It tests its precondition on entry and raises an exception when the position is out of range. This code is an original illustration written for this article, using Python's built-in exception mechanism.

Trace the two calls. The first call passes position 1, which lies in $[0, 3)$, so the check passes and the function returns the second item, b. The second call passes position 10, which lies outside the range, so the check fails and the raise statement runs. The line that would have returned an item is never reached. This is the divergence from the normal path: the expected return is replaced by an exception.

A try block can be followed by several catch blocks, and each one names the type of exception it handles. This lets one function respond differently to different kinds of failure. The sketch below shows the structure. The body of each handler is only a comment, because the point here is how try and catch blocks are arranged, not what each handler does.

Read the diagram as a decision made by exception type. If the try block completes without raising anything, no handler runs. If an exception is raised, its type decides which catch block receives it. The matching handler runs and the other handler is skipped. When the raised exception is a length error, the first handler matches, and the bad_alloc handler is ignored. When the raised exception is bad_alloc, the reverse happens.

The standard exception types such as std::length_error and std::bad_alloc are not the only option. You can define your own classes and use them as exceptions. A custom exception class carries arbitrary information from the place where an error is detected to the place where it can be handled. The class is more than a label. It is a container for whatever details the handler will need, while a standard type only tells the handler what category of problem occurred. The source states this purpose but does not show a full class definition, so this article does not present one. What matters is that the exception object is a vehicle for information, and its class defines what that information can look like.

Sometimes a function catches an exception, does something useful, and then decides the error should continue upward. The source calls this rethrowing. Inside a catch block, a bare throw; with no operand rethrows the caught exception so that it propagates further. The handler does not stop the error. It performs its own work, such as printing a message, and then hands the same error onward. Whether anything further up handles it depends on code outside this function, which the source does not show.

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

Tracing means following control one step at a time and recording where it goes. Use this method on the rethrowing version of test() shown above. Each trace below assumes a different exception type is raised, and checks each step against the code.