Modularity and Abstraction 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 a simple question: what changes when those two places are no longer the same, and why does that make planning ahead so important? The short answer is that the separation between detection and handling is not an accident. It is a direct consequence of how modern programs are organized into parts that hide their internal details.

The diagram below follows a run-time error from the work it was doing up to the point where a decision is made. Read it from top to bottom: the application calls into a library, the library's internal work code runs, and the error is first detected at a point inside that work. The handling point is where the program finally decides what the error means. The diagram shows the general shape of that relationship. It does not show a specific mechanism for passing the error along, because the source does not describe one.

Notice that the detection point and the handling point sit at different levels of the structure. The detection point is deep inside the work code, and the handling point is back in the application. Whatever path the error information takes between them, the program has to get the information from one place to the other, and that path crosses the library boundary.

Modularity and abstraction, which the source describes as central goals of C++ design, split a program into parts that hide their internal details. A library exposes what it offers to the outside world, while the code behind that interface stays out of sight. The calling application can use the library without knowing how the library does its work.

The hierarchy shows the two roles separated by a layer. The library sits between the application and the place where the problem is noticed. The application is the layer that knows enough about the overall task to decide what the problem means for the user. The library knows enough about its own work to notice that something has gone wrong, but it does not necessarily know what the application should do about it.

The central idea of this article is a separation. The point where a run-time error can be detected is not always the same as the point where it can be handled. A run-time error may be noticed in one place, and the response to it may need to happen in another. This separation is one of the effects of modularity and abstraction, especially when libraries are used.

Notice what this separation implies. Whoever writes the code that detects a problem may not be the person who decides how the program should respond. The detection point and the handling point have different responsibilities. Because of that, a program needs some shared understanding between them about what counts as an error and how errors are to be treated. Without that shared understanding, the detecting code and the handling code may each assume something different.

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 source describes an alternative: instead of building applications only from built-in types such as char, int, and double, and from statements such as if, while, and for, 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, and the algorithms sort(), find_if(), and draw_all().

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. A concrete illustration in the source 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 before the program runs.

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 above. 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, and an unplanned approach becomes harder to reason about.

The source frames this as something to design and articulate. That wording suggests the strategy should be stated clearly, not left implicit in the code. A strategy that exists only in one developer's head is hard to share, and it becomes harder to recover once the program has many files and many contributors.