Type System in Error Handling

Imagine a program small enough to fit in one file. When something goes wrong, the code that noticed the problem and the code that decides what to do about it are usually close together. You can read from top to bottom and see both.

Now imagine the same program has grown into dozens of files, uses several libraries written by other people, and is maintained by a team. The code that notices a problem may now be buried inside a library, while the decision about what the problem means belongs to the application that called it. This article asks what changes when those two places are no longer the same, and why that makes planning ahead so important.

Suppose a team builds an application that depends on a library for a particular task. Early in the project, the library is small and only a few people call it. Now follow a single error from start to finish. The application calls the library, the library calls deeper code, and somewhere in that deeper code the problem is first noticed.

Read the diagram from top to bottom. The problem is noticed at the bottom of the chain, inside the library, but the response belongs at the top, inside the application. The detection point and the handling point are separated by one or more layers of calls, and the error has to get from one to the other.

Modularity and abstraction are central goals of C++ design. They split a program into parts that hide their internal details. One effect of this, especially when libraries are used, is that the point where a run-time error can be detected is no longer the same as the point where it can be handled. A run-time error is noticed in one place, and the response to it may need to happen in another.

Before worrying about errors that cross boundaries, consider what the type system does to prevent mistakes in the first place. A program built only from the most basic types and statements has to be assembled piece by piece, and every piece is a place where something can go wrong.

The alternative the source describes is to avoid building applications only from built-in types such as char, int, and double, and from statements such as if, while, and for. Instead, a programmer builds additional types suited to the application, along with algorithms suited to those types. Examples named in the source include string, map, and regex as types, and sort(), find_if(), and draw_all() as algorithms.

The source gives two benefits of this approach. Higher-level constructs simplify programming and limit the opportunities for mistakes. They also increase the compiler's chances of catching errors. The source's concrete illustration is that a programmer is unlikely to apply a tree traversal to a dialog box, because the types involved do not fit together naturally. The type system makes that kind of mismatch easier to avoid and easier for the compiler to flag.

The source recommends a specific habit: design and articulate a strategy for error handling early in the development of a program. The reasoning follows from the separation described earlier. When a program is small, one person can keep the whole flow of errors in mind, and an informal approach may be enough. As programs grow and libraries are used more heavily, the number of detection points and handling points multiplies.