4.2.3 How to Raise a Condition How do you raise a condition? Well, there are really no explicit way in REXX to do that. The conditions are raised when an incident occurs. What sort of situations that is, depends on the context. There are in general three types of incidents, classified by the origin of the event: · Internal origin. The incident is only dependent on the behavior of the REXX script. The SYNTAX condition is of this type. · External origin. The REXX script and the interpreter has really no control over when this incident. It happens completely independent of the control of the REXX script or interpreter. The HALT condition is of this type. · Mixed origin. The incident is of external origin, but the situation that created the incident, was an action by the REXX script or the interpreter. The ERROR condition is of this type: the incident is a command returning error, but it can only occur when the interpreter is executing commands. For conditions trapped by method CALL, standard REXX requires an implementation to at least check for incidents and raise condition at clause boundaries. (But it is allowed to do so elsewhere too; although the actual triggering must only be performed at clause boundaries.) Consequently, you must be prepared that in some implementations, conditions trappable by method CALL might only be raised (and the trap triggered) at clause boundaries, even if they are currently trapped by method SIGNAL. The six standard conditions will be raised as result of various situations, read the section describing each one of them for more information. +-+ +-+ /-\ +-+ |Incident| |Condition | / Trap \ Off |Default | | occurs | > |is raised | > \ State / -> | action | +-+ +-+ \-/ +-+ / | /On |Delay / | / v +-+/ /-\ +-+ | Queue | Yes /DelayAction\ No |Ignore| |an event| <- \is queue? / -> |event | +-+ \-/ +-+ | v /-\ /Method is\ \ CALL? / \-/ \ / \ /No Yes\ / \ /-\ / \ / \ +-+ +-+ \ Decision / | Set state | | Set state | \-/ | OFF | | DELAY | +-+ +-+ +-+ | Trigger | | | | | | trap | | Return | | Action | +-+ +-+ +-+ The triggering of a condition When an incident occurs and the condition is raised, the interpreter will check the state of the condition trap for that particular condition at the current procedure level. · If the trap state is OFF, the default-action of the condition is taken immediately. The standard default-action is to ignore the condition. · If the trap state is DELAY, the action will depend on the delay-action of that condition. The standard delay-action is to ignore, then nothing further is done. If the delay-action is to queue, the interpreter continues as if the state was ON. · If the state of the trap is ON, an event is generated which describes the incident, and it is queued in the pending event queue. The further action will depend on the method of trapping. · If the method is CALL, the state of the trap will be set to DELAY. Then the normal execution is resumed. The idea is that the interpreter will check the event queue later (at a clause boundary), and trigger the appropriate trap, if it finds any events in the event queue. · Else, if method of trapping is SIGNAL, then the action taken is this: First set the trap to state OFF, then terminate clause the interpreter was executing at this procedure level. Then it explicitly trigger the condition trap. This process has be shown in the figure above. It shows how an incident makes the interpreter raise a condition, and that the state of the condition trap determines what to do next. The possible outcomes of this process are: to take the default-action; to ignore if delay-action is not to queue; to just queue and the continue execution; or to queue and trigger the trap.