4.2.6 Trapping by Method CALL
Assume that the condition MYTH is being trapped by method CALL,
that the state is ON and the handler is MYTH_HANDLER.

The following REXX clause will setup the trap correctly:

     CALL ON MYTH NAME MYTH_HANDLER

Now, suppose that the MYTH incident occurs. When the interpreter
senses that, it will raise the MYTH condition. Since the trap
state is ON and the trap method is CALL, it will create an event
and queue it in the pending event queue and set the trap state to
DELAY. Then it continues the normal execution. The trap is not
triggered before the interpreter encounters the next clause
boundary. What happens then?

·    At the every clause boundaries, the interpreter check for any
  pending events in the event queue.  If one is found, it is
  handled.  This action is done repeatedly, until the event queue is
  empty.

·    It will simulate a normal function call to the label named by
  the trap handler. As with any CALL clause, this will set the
  special variable SIGL to the line of from which the call was made.
  This is done prior to the call. Note that this is the current line
  at the time when the condition was raised, not when it was
  triggered.  All other actions normally performed when calling a
  subroutine are done.  Note that the arguments to the subroutine
  are set to empty.

·    However, just before execution of the routine starts, it will
  remove the first event in the pending event queue, the information
  is instead put into the current trapped condition. Note that the
  current trapped condition is information that is saved across
  subroutine calls. It is set after the condition handler is called,
  and will be local to the condition handler (and functions called
  by the condition handler). To the “caller” (i.e. the procedure
  level active when the trap was triggered), it will seem as if the
  current trapped condition was never changed.

·    Then the condition handler finishes execution, and returns by
  executing the RETURN clause. Any expression given as argument to
  RETURN will be ignored, i.e. the special variable RESULT will not
  be set upon return from a condition handler.

·    At the return from the condition handler, the current trapped
  condition and the setup of all traps are restored, as with a
  normal return from subroutine.  As a special case, the state of
  the trap just triggered, will not be put back into DELAY state,
  but is set to state ON.

·    Afterwards (and before the next normal clause), the
  interpreter will again check for more events in the event queue,
  and it will not continue on the REXX script before the queue is
  empty.

During the triggering of a trap by method CALL at a clause
boundary, the state of the trap is not normally changed, it will
continue to be DELAY, as was set when the condition was raised.
It will continue to be in state DELAY until return from the
condition handler, at which the state of the trap in the caller
will be changed to ON. If, during the execution of the condition
trap, the state of the condition being trapped is set, that change
will only last until the return from the condition handler.

Since new conditions are generally delayed when an condition
handler is executing, new conditions are queued up for execution.
If the trap state is changed to ON, the pending event queue will
be processed as named at the next clause boundary. If the state is
changed to OFF, the default action of the conditions will be taken
at the next clause boundary.


 PREV   NEXT