Traditional exception detection

Traditional exception handlers are procedural.

Procedural

Procedural exception handling breaks the normal flow of execution and executes a pre-registered exception handler. The details of how this is done depends on whether it is a hardware or software exception and how the software exception is implemented. Some exceptions, especially hardware ones, may be handled so gracefully that execution can resume where it was interrupted.  ( Wiki)

Validity testing

Alternative approaches to exception handling in software are error checking, which maintains normal program flow with later explicit checks for contingencies reported using special return values or some auxiliary global variable such as C's errno or floating point status flags; or input validation to premptively filter exceptional cases.  ( Wiki).

Reporting

Some programmers write software with error reporting features that collect details that may be helpful in fixing the problem, and display those details on the screen, or store them to a file such as a core dump, or in some cases an automatic error reporting system such as Windows Error Reporting can automatically phone home and email those details to the programmers ( Wiki).

Limitations

Procedural exception handlers enable detecting only part of the exceptional situations, often too late. Those exceptional situations not captured by the procedural exception handlers are often regarded as unexpected. The messages that the procedural handlers typically generate are useful for debugging, but are of low value for the operators. The reports generated provide low-quality feedback to the developers about ways to avoid the exceptions.

Common practices of exception handling enable disclosing part of the exceptional situations but not all of them:

• The handlers can capture exceptional situations only if they are predictable. Many exceptional situations are regarded as unpredictable. These include combination of states, operating under latent hazard, and operator’s unexpected activity.
• The handlers can capture the predictable exceptions only if the developers bothered to deal with them. Typically, developers focus on functionality, postponing the design and testing of exceptions to a late stage.

Example

Assume that in a nuclear power plant a backup pump has been closed for maintenance, and that the operators forgot to reopen it after finishing the maintenance activity. Assume that few days later, the primary pump stops working. Because the backup pump is closed, the core of the plant overheats and melts.

Note

This sequence of events is typical of many actual incidences. For example, exactly this sequence was the trigger of the famous Three Miles Island (TMI) accident in 1979, which had a profound effect on the nuclear community worldwide.

Accident analysis

For the discussion, assume that both the primary pump and the backup pump are attached with sensors designed to inform about the pump state. The question is if and how could procedural exception handling possibly prevent such incidences? Because it is procedural, we need to examine two procedures: one of tracing changes in the primary pump and the other of tracing changes in the backup pump.

• Case one: the procedure triggered by the sensor of the primary pump detects that the backup pump is closed, and generates an exception message. The problem is that it takes only few seconds for the core to overheat. By the time the operators receive the message, the core has already melted down.
• Case two: the procedure triggered by the sensor of the backup pump detects that the primary pump is operational. The problem is that the system design did not prohibit closing the backup pump, and the programmers did not provide a warning about it to the operators, because they assumed that temporarily closing the pump may be legitimate, and because they did not think of possible operator’s failure to reopen it afterwards.

Procedural exception handlers might fail to detect other failure modes occurring in the TMI accident, including those due to problems of sensor reliability or to misleading measurements.

Limitations of procedural exception detection

A primary limitation of procedural exception handling is the lack of means to identify hazards in time, before they materialize and threaten. Procedural exception handler might miss critical exceptions, such as:

• Inter-unit state mismatch, for example, in case of resetting one of the units
• Inconsistent mode setting, for example, due to an operator’s slip
• Mode errors: operating assuming the wrong mode

Examples

Regular exception handlers might not detect the exceptions resulting in the following accidents:

• Inconsistent mode setting: the Torrey Canyon environmental disaster in 1967, following unintentional setting of a control leve
• Inter-unit state mismatch: The friendly fire in Afghanistan 2001, following reset of the GPS following battery replacement.
• Mode errors: closing the backup pump of the TMI plant while producing energy.

Related topic

Updated on 03 Jun 2017.