Handling Errors Gracefully in Programs

When a program crashes, it is tempting to conclude that the program is wrong. The reasoning seems simple: if the program stops with an error, it must have failed, and if it stays calm and produces a neat result every time, it must be doing its job. This instinct feels reasonable, but it merges two separate questions that programmers need to keep apart. The first question is whether a program does its job. The second is whether it survives situations it was not meant to face. A program can answer yes to the first and no to the second, and the difference matters when you decide how to build and judge software.

The two ideas that this article separates are called correctness and robustness. Both are ways of evaluating a program, but they measure different things. The sections that follow start with a concrete program, make you predict how it should be judged, and then build the definitions from that example.

Imagine a program whose job is to read a list of numbers from the user and print them in sorted order. Suppose that for every valid list of numbers it sorts correctly. But when the user types a word such as seven instead of a number, the program stops with an error and quits. Before reading on, decide on two answers: would you call this program correct, and would you call it robust?

The key phrase is judged against the inputs it is meant to handle. Correctness is not measured against every imaginable input. It is measured against the inputs the program is supposed to accept. For the sorting program, the designed task is to read numbers and print them in sorted order. For that program to be correct, it has to produce sorted output for any set of input numbers. A single set of numbers that comes out unsorted is enough to show that the program fails its task.

Robustness is judged against different conditions than correctness. Correctness is tested with the inputs the program is supposed to handle, and asks whether it reaches its goal. Robustness is tested with inputs outside that expected range, and asks whether the program fails gracefully. Because the conditions differ, a program can pass one test and fail the other.

The standard for robustness is reasonableness, not perfection. The sorting program does not need to guess what the user meant by the word seven, and it does not need to recover every possible value. It needs to avoid a crash or nonsensical output, and to respond in a way a sensible person would consider acceptable. The source contrasts a robust response, which prints an error message and ignores the bad input, with a non-robust program that might crash or give nonsensical output when it meets the same bad input.

The flowchart below follows a single item of input through the sorting program. The key question is what happens at the decision point: when the input is illegal, does the program reject it, recover, or crash? A robust program sends illegal input down a path that reports the problem and continues. A non-robust program has no such path, so the bad input falls through to a failure.

The flowchart has two branches for illegal input. The robust branch reports the error and ignores the bad input, so the program keeps going and can still produce a sorted result from the valid items. The non-robust branch ends in a crash. Both programs can be correct on valid lists; the only difference is what they do on the illegal path.

Graceful handling is easiest to see as a sequence of exchanges. The user supplies input, the program detects that the input is illegal, an error handling step produces a message, and the program continues rather than stopping. The diagram shows the order in which these three parties exchange input, failure, and message.

The error message is part of the robust response. The source describes a program that prints an error message and ignores the bad input. The message tells the user what went wrong, and the program does not depend on guessing what the user meant. The purpose is a reasonable reaction, not a perfect interpretation of every mistake.

The two properties are easiest to tell apart by comparing two programs, each of which has one property without the other. The first program is correct but not robust, like the sorting program that crashes on seven. The second is robust but not correct: it prints a friendly error message for every input, including valid lists, and never sorts anything. Its handling of bad input looks polite, but it fails its designed task.

The source makes a clear distinction here. Every program should be correct. Not every program needs to be completely robust. Whether a program needs more robustness depends on who will use it and how it will be used. Robustness is a design decision about how much care the situation deserves, not a checkbox every program must tick.