Exception Handling

Abstract

Translating abstract concepts and descriptions of business practices and rules into process models is a far from trivial exercise. Even for highly structured processes (such as medical and banking environments), it is difficult (if not impossible) to successfully capture all work activities, and in particular all of the task sequences possible, in a workflow model, at least not without producing some very complex models. In fact, it is because of the discrepancies between real-world activities and formal representations of them that workflow process instances typically experience exceptions during their execution.¹ Traditionally, exceptions are understood to be events that by definition occur rarely. But in a workflow process, an exception can be described as an event that is deemed to be outside “normal” behavior for that process. Rather than being an error, it is simply an event that is considered to be a deviation from the expected control-flow or was unaccounted for in the original process model. Such events happen frequently in real working environments. Exceptions are a fundamental part of most organizational processes; in fact, a substantial proportion of the everyday tasks carried out in a business can be categorized as exception handling work. Consequently, every executing instance of a work process will be likely to incorporate some deviation from the plan. In this sense, a work plan can be seen to be just another resource or tool that mediates the activities of workers towards their objective, rather than a prescriptive blueprint that must be strictly adhered to. Such deviations from the plan should not be considered as errors, but as a natural and valuable part of the work activity, which provides the opportunity for learning and thus evolving the plan for future instantiations. Historically, exception handling within PAIS has fallen well short, particularly after execution has commenced. It is assumed that if an exception is expected, or even could conceivably have been anticipated, then the modeler has a priori knowledge of such an event, and it should therefore have been built into the model. However, if a modeler builds all possible a priori exception scenarios into a model, it can lead to very complex models, much of which will never be executed in most cases. Also, mixing business logic with exception handling routines complicates the verification and modification of both, in addition to rendering the model almost unintelligible to most stakeholders.