Role of the Type System in Error Prevention

Imagine a program that works well in testing but fails once it is used for real. A file is missing, a network connection drops, or a value arrives in a shape nobody expected. In each case something has gone wrong while the program is running, and the program now has to respond. Responding well raises two questions. The first is how to respond. The second, which is often harder, is 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.

Error handling is a large and complex subject. Its concerns reach well beyond what a programming language's built-in features can address, into programming techniques and tools. The language still offers real help, and the most important of that help comes from the type system. This article explains how the type system prevents many errors before they happen, and why the question of who handles an error is tied to how the program is structured.

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 often are not even in the same part of the program. A function may be the first place that discovers a bad value, while a different function, higher up the chain of calls, is the one that knows what the user needs or what the application should do next.

The diagram below shows a generated example of this situation. A main routine starts a batch job, which calls a routine that loads records, which in turn calls a routine that parses one value and finds it malformed. The parsing routine is the place where the problem is noticed. The main routine is the place that can decide whether to skip the record, stop the batch, or report the failure. Read the diagram from top to bottom as a chain of active calls. Each box is still waiting for the box below it to return when the error is detected.

The source attributes the separation between detection and handling to modularity and abstraction. Good program design divides work into modules, and a module often hides its internal details behind an interface. A library, for example, may be written to perform one 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, because that knowledge belongs to the code that calls the library. Modularity makes the code clean, and it is also what creates the gap between noticing a problem and responding to it.

The module that detects a problem often lacks the context needed to choose a response. This is the main reason the detection point and the handling point frequently differ. The detecting module knows that its own work failed. It does not know whether the failure is fatal for the whole program, whether a retry would help, or whether the user should be told. The calling code usually knows those things, so the problem has to travel across the interface to reach it.

The flowchart below traces that journey in general terms. It does not depend on any particular language mechanism. The detection happens inside the module, where the relevant knowledge lives. The handling decision happens outside it, where the application's goals are known. The interface between them is the path the problem must travel. Follow the arrows from the top, and notice that the decision is made at the caller, not at the place of detection.

Consider two ways of building a program. In the first, every piece of data is stored in the most basic containers the language provides, such as single characters, plain integers, and floating-point numbers. Every behavior is assembled from basic statements such as 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. Then the programmer defines algorithms that operate on those richer types. The second approach is the one the source describes as the major tool for error prevention in C++.

The diagram places the two designs side by side. On the left, the program is built from generic pieces that make almost any combination possible. On the right, the program is built from types and algorithms shaped around the application. The number of meaningful operations is much smaller on the right, and that is the point of the design.

The reason 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 gives a vivid example: you are unlikely to try to apply a tree traversal to a dialog box. Because the types and algorithms are shaped around the application, there are fewer chances to combine them incorrectly.

Prevention happens at two levels. The programmer chooses abstractions that rule out many mistakes, and the compiler checks the remaining uses against the declared types. Higher-level types give the compiler more to work with, and the source notes that such constructs increase the compiler's chances of catching errors. The two levels work together, so a design that offers the compiler clear types leaves fewer errors for the run-time to reveal.

A small program often has one author and one place where everything happens, so detection and handling are usually close together. As a program grows, its code is split into modules and begins to depend heavily on libraries written by other people. The source notes that this is when standards for handling errors become important, especially when libraries are used extensively. The source recommends designing and articulating a strategy for error handling early in the development of a program, because the separation between detection and handling is built into the program's structure from the start.