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