Default Actions for Unhandled Exceptions

If you do not handle an exception message in your HLL, the system takes a default action for the unhandled exception.

Figure 1 shows the default actions for unhandled exceptions based on whether the exception was sent to an OPM or ILE program. Different default actions for OPM and ILE create a fundamental difference in error handling capabilities.

For OPM, an unhandled exception generates a special escape message known as a function check message. This message is given the special message ID of CPF9999. It is sent to the call message queue of the call stack entry that incurred the original exception message. If the function check message is not handled, the system removes that call stack entry. The system then sends the function check message to the previous call stack entry. This process continues until the function check message is handled. If the function check message is never handled, the job ends.

For ILE, an unhandled exception message is percolated to the previous call stack entry message queue. Percolation occurs when the exception message is moved to the previous call message queue. This creates the effect of sending the same exception message to the previous call message queue. When this happens, exception processing continues at the previous call stack entry.

Percolation of an unhandled exception continues until either a control boundary is reached or the exception message is handled. The processing steps taken when an unhandled exception percolates to a control boundary depend on the type of exception:

If it is a status exception, the exception is handled and the sender of the status is allowed to continue.
If it is a notify exception, the default reply is sent, the exception is handled, and the sender of the notify is allowed to continue.
If it is an escape exception, a special function check message is sent to the resume point. This function check may be handled, or it may percolate to a control boundary (see below).
If it is a function check, ILE considers the application to have ended with an unexpected error. All call stack entries up to and including the control boundary are cancelled. If the control boundary is the oldest invocation associated with a non-default activation group, the activation group is ended. A generic failure exception message is defined by ILE for all languages. The message identifier for this message is CEE9901, and is sent by ILE to the call stack entry immediately preceding the control boundary.

Figure 1 shows an unhandled escape exception within ILE. In this example, the invocation of procedure P1 is a control boundary and is also the oldest invocation entry for the associated activation group. Procedure P4 incurs an escape exception. The escape exception percolates to the P1 control boundary and as a result the special function check message is sent to procedure P3’s resume point. The function check is not handled and percolates to the P1 control boundary. The application is considered to have ended and the activation group is destroyed. Finally, the CEE9901 escape exception is sent to the call stack entry immediately preceding the control boundary (program A).

The default action for unhandled exception messages defined in ILE allows you to recover from error conditions that occur within a mixed-language application. For unexpected errors, ILE enforces a consistent failure message for all languages. This improves the ability to integrate applications from different sources.

Figure 1. Unhandled Exception Default Action