4.2.5 Trapping by Method SIGNAL
Assume that a condition is being trapped by method SIGNAL, that
the state is ON and the handler is MYTH_TRAP. The following REXX
clause will setup the trap correctly:

     SIGNAL ON MYTH NAME MYTH_TRAP

Now, suppose the MYTH incident occurs. The interpreter will sense
it, queue an event, set the trap state to OFF and then explicitly
trigger the trap, since the method is SIGNAL. What happens when
the trap is triggered?

·    It collects the first event from the queue of pending events.
  The information is removed from the queue.

·    The current trapped condition is set to the information
  removed from the pending event queue.

·    Then, the interpreter simulates a SIGNAL clause to the label
  named by trap handler of the trap for the condition in question.

·    As all SIGNAL clauses, this will have the side-effects of
  setting the SIGL special variable, and terminating all active
  loops at the current procedure level.

That’s it for method SIGNAL. If you want to continue trapping
condition MYTH, you have to execute a new SIGNAL ON MYTH clause to
set the state of the trap to ON. But no matter how quick you reset
the trap, you will always have a short period where it is in state
OFF. This means that you can not in general use the method SIGNAL
if you really want to be sure that you don’t loose any MYTH
events, unless you have some control over when MYTH condition may
arise.

Also note that since the statement being executed is terminated;
all active loops on the current procedure level are terminated;
and the only indication where the error occurred is the line
number (the line may contain several clauses), then it is in
general impossible to pick up the normal execution after a
condition trapped by SIGNAL.  Therefore, this method is best
suited for a “graceful death” type of traps. If the trap is
triggered, you want to terminate what you were doing, and pick up
the execution at an earlier stage, e.g. the previous procedure
level.



PREV NEXT