Modularity and Abstraction in C++ Programs

Imagine a program that works well during testing but fails in the field. A file it expected is missing, a network connection drops in the middle of a task, or a value arrives in a shape nobody anticipated. Something has gone wrong while the program is running, and the program now has to respond.

This article is about a question that follows from that situation. It is not only how to respond to a problem, but which part of the program should be responsible for responding, and how that responsibility is divided between the code that notices the problem and the code that decides what to do about it. The answer depends on how the program is organized into modules and abstractions, so the two ideas are taken together here.

The subject is large. Error handling reaches well beyond what a programming language's built-in features can address, into programming techniques and tools. The language does still provide some help, and the most important of that help comes from the type system. Both the separation between detecting and handling errors and the type system's role in preventing them are covered below.

Programs are built from modules, and modules call one another. Picture a chain of calls: the main part of the program calls application logic, the application logic calls a library function, and the library function calls an internal step that does a piece of the library's specific job. When the internal step finds that something has gone wrong, it is the first place that knows about the problem. The question is what happens next.

The diagram shows four frames stacked in the order they were called. The lowest frame is where the problem is detected, because that is where the relevant knowledge lives. The frames above it are where the decision about what the problem means for the whole application can be made. Control has to travel back up through the chain for the problem to reach the code that can respond.

The central idea of this part of the material is that the point where a run-time error can be detected is often separated from the point where it can be handled. These two points are not automatically the same line of code, and they are often not even in the same part of the program. The source attributes this separation to modularity and abstraction.

Consider a library written to perform a specific job. The code inside that library is in the best position to notice that something has gone wrong with its own work. It is frequently not in the best position to decide what the overall application should do about it. That decision depends on the application's goals, and those goals are known to the code that calls the library. Modularity is what makes the code clean, and it is also what creates the gap between noticing a problem and responding to it.

A small program often has one author and one place where everything happens, so the detection point and the handling point usually sit close together. The gap becomes significant as the program grows, its code is split into modules, and it relies heavily on libraries written by other people.

Now trace a single error step by step. The question for each step is the same: does this piece of code have the context needed to choose a response, or should it pass the problem on? The flowchart below follows a failed lookup from the internal step where it is detected to the application code where it can be handled.

Detecting and handling errors is only one part of the story. The source identifies the type system as the major tool C++ offers for preventing errors in the first place. Higher-level types and algorithms limit the opportunities for mistakes and help the compiler catch the ones that remain.

The source describes two ways of building a program. In the first, all data is stored in the most basic containers the language provides, such as single characters, plain integers, and floating-point numbers, and all behavior is assembled from basic statements like conditionals and loops. In the second, the programmer first defines richer types that match the application, such as a string type, an associative map type, and a pattern-matching type, and then defines algorithms that operate on those richer types. The second approach is the one the source describes as the major tool for error prevention.

The reason the richer types help is that higher-level constructs make certain mistakes hard to write in the first place. A well-designed type limits the operations that make sense on it. A programmer working with the right abstraction is unlikely to attempt an operation that belongs to an entirely different domain. The source's example is that you are unlikely to apply a tree traversal to a dialog box. Because types and algorithms are shaped around the application, there are fewer chances to combine them incorrectly.

Higher-level types also give the compiler more to work with, and the source notes that such constructs increase the compiler's chances of catching errors. Prevention therefore happens at two levels. The programmer chooses abstractions that rule out many mistakes, and the compiler checks the remaining uses against the declared types.

As programs grow and rely on libraries, standards for handling errors become important. The source notes that this is especially true when libraries are used extensively, because the code is then spread across many modules that different people wrote.

Without shared standards, each module may invent its own way of signaling problems, and the people writing the calling code may not know what to expect. A consistent approach means that when an error is detected in one module, the rest of the program has a predictable way to learn about it and respond. The handling side can then be written against a known pattern rather than guessed at.

The source recommends designing and stating a strategy for error handling early in a program's development. The reason is that the separation between detection and handling is built into the program's structure. Once modules, interfaces, and libraries are in place, the question of how problems travel across them is already partly answered, whether or not anyone chose the answer deliberately.