Exception Handling Overview

Exception handling is the process of:

• Examining an exception message which has been issued as a result of a run-time error
• Optionally modifying the exception to show that it has been received (that is, handled)
• Optionally recovering from the exception by passing the exception information to a piece of code to take any necessary actions.

When a run-time error occurs, an exception message is generated. An exception message has one of the following types depending on the error which occurred:

*ESCAPE

Indicates that a severe error has been detected.

*STATUS

Describes the status of work being done by a program.

*NOTIFY

Describes a condition requiring corrective action or reply from the calling program.

Function Check

Indicates that one of the three previous exceptions occurred and was not handled.

Exception messages are associated with call stack entries. Each call stack entry is in turn associated with a list of exception handlers defined for that entry. (See The Call Stack for further discussion of a call stack.)

Figure 134 shows a call stack where an OPM program calls an ILEprogram consisting of several modules and therefore several procedures. Refer to this figure in the discussions which follow.

In general, when an exception occurs, the handlers associated with the call stack entry are given a chance to handle the exception. If the exception is not handled by any of the handlers on the list then it is considered to be unhandled, at which point the following default actions are taken for the unhandled exception:

1. If the exception is a function check, the call stack entry is removed from the stack.
2. The exception is moved (percolated) to the previous call stack entry.
3. The exception handling process is restarted for this call stack entry.

The action of allowing the previous call stack entry to handle an exception is referred to as percolation. Percolation continues until the exception is handled, or until the control boundary is reached. A control boundary is a call stack entry for which the immediately preceding call stack entry is in a different activation group or is an OPM program. In Figure 134 Procedure P1 is the control boundary.

Figure 134. Call Stack and Exception Message Percolation

In OPM, the exception message is associated with the program which is active on the call stack. If the exception is not handled by the associated exception handlers, then a function check is sent to the same call stack entry which received the exception. If it remains unhandled, then the entry is removed and the function check is percolated. The process repeats until the exception is handled.

In ILE, an exception message is associated with the procedure which is active on the call stack. When the exception is percolated, it is not converted to a function check. Each call stack entry is given a chance to handle the original exception until the control boundary is reached. Only then is the exception converted to a function check, at which point the exception processing starts all over again beginning with the procedure which received the exception. This time each call stack entry is given a chance to handle the function check. If the control boundary is reached and the exception is still unhandled then a generic failure exception message CEE9901 is sent to the caller of the procedure at the control boundary. In addition, any call stack entry which did not to handle the message is removed.