This scenario describes the behavior of an application that contains
a C++ and
a PL/I routine.
Refer to Figure 1 throughout the following
discussion. In this scenario, a PL/I main
routine invokes a C++ subroutine.
An exception occurs in the C++ subroutine.
Figure 1. Stack contents when the exception
occurs in C++
The actions taken are the following:
- In the enablement step, it is determined whether the exception
in the C++ routine
should be enabled and treated as a condition. If any of the following
are true, the exception is ignored, and processing continues at the
next sequential instruction after where the exception occurred:
If you did none of these things, the condition is enabled and
processed as a condition.
- If a user-written condition handler has been registered on the
stack frame using CEEHDLR, it is given control.
If it issues a
resume, the condition handling step ends. Processing continues in
the routine to which the resume cursor points.
In this example,
no user-written condition handler is registered for the condition,
so the condition is percolated.
- If a C signal handler has been registered for the condition on
the C++ stack
frame, it is given control. If it successfully issues a resume or
a call to longjmp(), the condition handling step
ends. Processing resumes in the routine to which the resume cursor
points.
In this case, there is not a C signal handler registered
for the condition.
- The condition is still unhandled. If C++ does not recognize the
condition, or if the C++ default action (listed in Table 2) is to terminate,
the condition is percolated.
- Is a user-written condition handler has been registered on the PL/I stack
frame using CEEHDLR, it is given control. If it issues a resume, the
condition handling step ends. Processing continues in the routine
at the point where the resume cursor points. In this example, no user-written
condition handler is registered for the condition, so the condition
is percolated.
- If an ON-unit has been established for the condition being processed
on the PL/I stack
frame, it is given control. If it issues a GOTO out-of-block, the
condition handling step ends. Execution resumes at the label of the
GOTO. In this example, no ON-unit is established for the condition,
so the condition is percolated.
- What happens next depends on whether the condition is promotable
to the PL/I ERROR
condition. The following can happen:
- If the condition is not promotable to the PL/I ERROR
condition, then the Language Environment default
actions take place, as described in Table 1. Condition handling
ends.
- If the PL/I default
action for the condition is to promote it to the PL/I ERROR
condition, the condition is promoted, and another pass is made of
the stack to look for ERROR ON-units or user-written condition handlers.
If an ERROR ON-unit or user-written condition handler is found, it
is invoked.
- If either of the following occurs:
- An ERROR ON-unit or user-written condition handler is found, but
it does not issue a GOTO out of block or similar construct
- No ERROR ON-unit or user-written condition handler is found
then the ERROR condition is promoted to T_I_U (Termination Imminent
due to an Unhandled condition). Condition handling now enters the
termination imminent step. Because T_I_U maps to the PL/I FINISH
condition, a FINISH ON-unit or user-written condition handler is run
if the stack frame in which it is established is reached.
- If no condition handler moves the resume cursor and issued a resume, Language Environment terminates
the thread.