This is an old revision of the document!
Exception Handling
The following examples demonstrate how sequences and their monitors are able to handle various scenarios.
Sequence Supervised by Monitor
The situation below shows a monitor firing during the runtime of a sequence.
As soon as a monitor checking for a certain condition fires, an exception sequence is called. The exception must always be blocking. However, it would be possible to omit it altogether. After this the control goes back to the original sequence. How does this sequence now continue? Every monitor can be assigned one of the following properties:
- nothing: the sequence continues normally
- abortOwner: the sequence is aborted and control goes back to its calling sequence
- restartOwner: the sequence gets restarted, its timeout monitor is reset (that's the situation shown in the figure above)
- abortCallerOfOwner:
- restartCallerOfOwner:
The following table shows the behavior for various situations
| Property | behavior of sequence after monitor fires | exception sequence if present |
|---|---|---|
| nothing | sequence continues normally | exception sequence will run for each further step |
| abortOwner | remaining steps aborted | exception sequence will run once |
| restartOwner | remaining steps aborted, sequence restarts with first step | exception sequence will run once, after restarting will run again if monitor fires again |
Sequence Supervised by more than one Monitor
A sequence can be checked by more than one monitor where each monitor checks for a certain condition to be met. While a first monitor could check for a timeout condition a second could supervise whether a payload of a robot didn't get lost.
Please note, that each monitor can have a different effect on its associated sequence.