The condition step begins after the enablement step has completed
and Language Environment determines
that an exception in your application should be handled as a condition.
In the simplest form of this step, Language Environment traverses
the stack beginning with the stack frame for the routine in which
the condition occurred and progresses towards earlier stack frames.
Condition handlers are invoked at each intervening stack frame and
given a chance to respond in any of the ways described in Responses to conditions. The condition step lasts until
a condition handler requests a resume or until default condition handling
occurs (condition went unhandled). Throughout the following discussion,
refer to Figure 1.
Figure 1. Condition
processing
- Language Environment condition
handling begins at the most recently activated stack frame. This is
the stack frame associated with the routine that incurred the condition.
In Figure 1, this is A, or routine
4.
- If the debug tool is present, and the setting of the TEST runtime
option indicates that it should be given control, it is invoked. See z/OS Language Environment Programming Reference for
information about the TEST runtime option.
- If the debug tool is not invoked, or does not handle the condition, Language Environment traverses
the stack, stack frame by stack frame, towards earlier stack frames.
This is in the direction of arrow B in Figure 1. User-written condition handlers established
using CEEHDLR, and then language-specific condition handlers present
at each stack frame such as C/C++ signal
handlers or PL/I ON-units,
can all respond by percolating, promoting, or handling the condition
(see Responses to conditions for a discussion of these
actions).
- Condition handling is complete if one of the handlers requests
the application to resume execution. If all stack frames have been
visited, and no condition handler has requested a resume, the language
of the routine in which the exception occurred can enforce default
condition handling semantics.
- If the HLL of the routine that originated the condition does not
issue a resume, what occurs next depends on whether there is a PL/I routine
active on the stack.
- The condition is percolated if there is no currently active PL/I routine
or if the condition is not one that PL/I promotes
to the ERROR condition (see Promoting conditions to the PL/I ERROR condition for
details). Language Environment default
actions are then taken based on the severity of the unhandled condition,
as indicated in Table 1.
If the condition is of severity 2 or above, Language Environment promotes
the condition to T_I_U (termination imminent due to an unhandled condition)
and returns to routine 4 to redrive the stack (this occurs at points C and D in Figure 1). For more information about the termination
imminent step and T_I_U, see Termination imminent step.
- If the condition is one that PL/I promotes
to the PL/I ERROR
condition (see Promoting conditions to the PL/I ERROR condition for details),
the condition is promoted at the location represented as C in Figure 1, and another pass is made of the stack.
The following takes place:
- On the next pass of the stack (D), any ERROR ON-unit or
user-written condition handler is invoked. If the ON-unit or user-written
condition handler issues a resume, condition handling ends. Execution
resumes where the resume cursor points.
- If no ON-unit or user-written condition handler issues a resume,
the ERROR condition is promoted (at E) to T_I_U. (See Processing the T_I_U condition for a discussion of T_I_U.)
- A final pass of the stack is made, beginning in Routine 4 where
the original condition occurred (F). Because T_I_U maps to
the PL/I FINISH
condition, both established PL/I FINISH
ON-units and user-written condition handlers registered for T_I_U
are invoked.
- If no user-written or HLL condition handlers act on the condition, Language Environment begins
thread termination activities in response to the unhandled condition
(G). See Table 1 for
the default actions that Language Environment takes
for conditions of different severities.