Exceptions for Dependability

Introduction

A program may fail to perform its intended task for three reasons:

• •

  The specification may be in error. It may not capture the user's requirements, or the requirements are inconsistent or incomplete.

• •

  There may be errors in the design. There errors arise from incorrect arguments that the program meets its specification (e.g. overlooking a case), or from idealized or incorrect assumptions about the programming language, libraries, and the hardware (e.g. a sufficiently large integer range and sufficiently available memory).

• •

  The underlying software or hardware may fail, (e.g. operating system, disk, memory, or network).

Some failures are always detected at run-time by the underlying (virtual) machine (e.g. indexing an array out of bounds, allocating memory when none is available, or reading a file beyond its end). Other failures may be detected by programmer-added checks (e.g. checking the range of parameters of a procedure). Finally, some failures are too difficult to detect by any means.

The possibility of a failure is present even when the best effort is put forth to design error-free programs. The question then arises how programs should respond to detected failures. Suppose that a problem calls for the sequential composition of four statements,S₁ ; S₂ ; S₃ ; S₄and statements S₁ and S₃ may fail in a detectable way. In case they do fail, the sequence should be abandoned and statement T should be executed instead. In the a priory scheme, we add a test before running S₁ and S₃. In the a posteriori scheme, we run S₁ and S₃ and test if they were successful (see Box 1).