Exception Handling Mechanisms: High-Level Error Control

• heap space exhaustion when NEW is called,
• division by 0,
• file opening fails.

If a procedure cannot continue because of an exception, its caller might be able to handle it.

• heap space exhaustion: caller might use a more time-consuming, but less space-consuming calculation,
• division by 0 in a matrix inversion procedure: caller can invoke code for singular matrices,
• file opening fails due to incorrect file or path: user can be prompted for the correct file.

• software which continues to function in the presence of errors,
• this is especially important in embedded systems applications, e.g, aircraft control software.

Exception Handling Constructs

In general, exceptions are defined as the names of anomalous conditions:

• Languages may provide predefined exceptions, such as ZERODIVIDE in PL/I and STORAGE_ERROR in Ada.
• Users may declare their own exceptions.

Raising (throwing in Java) an exception signals that an anomalous condition has occurred.

• Predefined exceptions are generally raised automatically by the language's run-time support software.
• User-defined exceptions are raised by explicit raise (throw) statements.

An exception handler is a segment of code that is designed to be activated when the corresponding exception is raised. Typically an exception handler is associated with a segment of code and is used to handle any exceptions that arise in execution of the code.

For example in Modula-3:

EXCEPTION BadFormat;
...
TRY
  stmts
EXCEPT
  BadFormat => handler-stmts
END;

Modula-3 also provides a clean-up style of handler that catches any exception whatsoever.

TRY stmts
FINALLY cleanup-stmts
END;

Modula-3 and other modern languages (e.g., CLU, Ada) statically bind handlers to particular code segments.
In PL/I, the binding of handlers is dynamic; the current handler in force for a given exception could be changed at any time under the control of the programmer.

Data Communication

1. Using global variables: (Ada, PL/I).
   This is the simplest mechanism, but can be awkward to program and difficult to read.

2. Using parameterized handlers: (Modula-3, CLU).
   For example in Modula-3:

   EXCEPTION BadFormat(Text);
   ...
   TRY
     stmts
   EXCEPT
     BadFormat(theString) => 
       PutText("Enter a replacement for |" 
              theString"|.")
   END;
   

   This approach is somewhat more complex and less efficient, but provides greater flexibility and readability.
3. Using exception objects: (Java).

   public class FileNotFoundException extends IOException {
           public FileNotFoundException();
           public FileNotFoundException(String s);
   

   An elegant approach that also uses the subtype hierarchy for catching exceptions.

Exceptions and Procedure Interfaces

In general, the idea of raising an exception is to signal a condition that cannot be dealt with by the current procedure. Thus the current procedure terminates abnormally and passes the exception to its caller.

In Modula-3, CLU, and Java, the possibility that a procedure raises an exception is considered part of its input-output specification and must be explicitly declared in the procedure heading.

PROCEDURE ScanRealNumber 
             (str : Text) : REAL RAISES {BadFormat};

If a procedure terminates due to an exception, but that procedure does not specify it in the header, then

• a special failure exception is raised in CLU.
• a checked run-time error occurs in Modula-3.

In other languages the exception may be propagated back to the caller of the procedure and the caller's caller and so on until a handler is found. This is true in Modula-3 only so long as each procedure header properly declares the exception.

Checking. Compilers can check whether clients of procedures

• handle each possible exception, or
• declare the exception as a possible result
  (automatic propagation)