Page 376 -

13.4 Dependable programming 359

may indicate that an exception has occurred so that a calling component is
aware of the problem.
3. Pass control to a run-time support system that handles the exception. This is
often the default when faults occur in a program (e.g., when a numeric value
overflows). The usual action of the run-time system is to halt processing. You
should only use this approach when it is possible to move the system to a safe
and quiescent state, before handing control to the run-time system.

Handling exceptions within a program makes it possible to detect and recover
from some input errors and unexpected external events. As such, it provides a degree
of fault tolerance—the program detects faults and can take action to recover from
these. As most input errors and unexpected external events are usually transient, it is
often possible to continue normal operation after the exception has been processed.

Guideline 4: Minimize the use of error-prone constructs
Faults in programs, and therefore many program failures, are usually a consequence
of human error. Programmers make mistakes because they lose track of the numer-
ous relationships between the state variables. They write program statements that
result in unexpected behavior and system state changes. People will always make
mistakes, but in the late 1960s it became clear that some approaches to programming
were more likely to introduce errors into a program than others.
Some programming language constructs and programming techniques are inher-
ently error prone and so should be avoided or, at least, used as little as possible.
Potentially error-prone constructs include:

1. Unconditional branch (go-to) statements The dangers of go-to statements were
recognized as long ago as 1968 (Dijkstra, 1968) and, as a consequence, these
have been excluded from modern programming languages. However, they are
still allowed in languages such as C. The use of go-to statements leads to
‘spaghetti code’ that is tangled and difficult to understand and debug.

2. Floating-point numbers The representation of floating-point numbers in a fixed-
length memory word is inherently imprecise. This is a particular problem when
numbers are compared because representation imprecision may lead to invalid
comparisons. For example, 3.00000000 may sometimes be represented as
2.99999999 and sometimes as 3.00000001. A comparison would show these to
be unequal. Fixed-point numbers, where a number is represented to a given
number of decimal places, are generally safer because exact comparisons are
possible.
3. Pointers Programming languages such as C and C++ support low-level con-
structs called pointers, which hold addresses that refer directly to areas of the
machine memory (they point to a memory location). Errors in the use of point-
ers can be devastating if they are set incorrectly and therefore point to the wrong