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.


 PREV   NEXT