Page 164 -

154 M. Adams and N. Russell
5.2.5 Characterizing Exception Handling Strategies

Having described the various factors that are relevant when handling a specific
exception, it is now possible to provide a precise means of categorizing an excep-
tion handling strategy in the form of a pattern that succinctly describes the form
of recovery that will be attempted. Exception patterns take the form of four-tuples
comprising the following elements:
The type of exception detected
How the task on which the exception is based should be handled
How the case and other related cases in the process model in which the exception
is raised should be handled
What recovery action (if any) is to be undertaken

For example, the pattern WIF-SFF-CWC-COM specified for a work item failure
exception for the Investigate Customer Complaint task in the Respond to Billing
Dispute process indicates that if failure of a work item corresponding to the Inves-
tigate Customer Complaint task is detected when it has been started, then the work
item should be terminated, have its state changed to failed and the nominated com-
pensation task should be invoked. No action should be taken with other work items
in the same case. It is important to note that this pattern only applies to instances of
the work item that fail once started; it does not apply to instances in the offered or
allocated states (which if required should have distinct patterns nominated for them).
From the various alternatives identified for each of these elements in Sect. 5.2.2–
5.2.4, there are 135 possible patterns that can be conceived. Not all patterns apply
to a given exception type, however, and Table 5.2 identifies those that apply to each
of the exception types identified in Sect. 5.2.1.

5.3 YAWLeX: A Graphical Exception Handling Language

YAWLeX is an exception handling language that allows resolution strategies defined
in terms of the exception patterns to be described using a graphical notation.
YAWLeX is intended to be both compact and generic in nature. It is comprised
of a set of primitives that support various aspects of exception handling. The vari-
ous primitives that make up the language are illustrated in Fig. 5.2. These primitives
can be assembled into sequences of actions that define exception handling strate-
gies. These sequences may theoretically also contain standard YAWL constructs,
although that capability is not illustrated here.
The interlinkage of exception handling strategies based on these primitives and
the overall process model is illustrated in Fig. 5.3. A clear distinction is drawn
between the process model and the exception handling strategies. This is based on
the premise that the process model should depict the normal sequence of activities