BulePrism进阶教程-8. Error Management

There are two main features of Error Management:
First, the occurrence of unexpected events in a Process or Business Object can be identified (or to use a programming analogy, caught). This gives the developer the opportunity to build additional robustness into the logical flow in an attempt to handle the unexpected. For example, by taking the flow along a different route or by repeating the sequence that failed.
Second, cases that could not be worked can be identified. If, for whatever reason, a case cannot be completed, rather than stopping, the case can simply be marked as an exception and the process can move on to the next case. As you may have realized, this feature is naturally related to Case Management.
In our previous examples and exercises, we have only looked at ideal scenarios and have not really considered what to do when things do not go to plan. In the real world, problems will inevitably occur and we should aim to create a robust solution capable of dealing with them. Thorough testing should reveal the most common problems and we can then make adjustments for them.
We have seen how to use a Wait stage to allow a Business Object to pause for an application, but as yet we have not considered what to do if our Wait stage times out. Maybe a simple retry is enough to resolve an issue, or perhaps there is something unusual with the data we are working with (e.g., a suspended account) and retrying is of no use. It would be better to make a note of the problem and move on.
Simply moving to the next job might be enough, or it could be that we need to make a fresh start and restart the target application(s). More seriously, there could be a problem that is beyond our control (e.g., an application is offline) and we have no choice but to stop completely.
These kinds of problems and errors are known as exceptions, and the logic used to cater for them is known as exception handling.
8.1. Exception Handling
Rather than failing in the event of an exception, Processes and Business Objects can be designed to handle the exception and try to keep going.
Although not every type of exception is recoverable, and sometimes it makes no sense to attempt a recovery, the ability to handle exceptions at least provides us with the opportunity to decide what to do when something goes wrong and the logical flow has strayed from the ideal path.
We have seen that a solution is formed by Processes and Business Objects. Exceptions can potentially occur at any point and we shall see how exceptions are handled in such an arrangement.
Exception handling is done with a set of stages we have not used before.
8.2. Recover and Resume
As the names suggest, Recover and Resume are stages used to attempt to salvage and move on from an exception. The use of these kinds of stages also introduces a new concept to the design of a diagram.
Exercise 8.2.1 Recovering from an Exception
 Create a new Business Object named Exception Exercises Object.
 Add two number Data Items named X and Y with initial values of 1 and 0.
 Add a Calculation stage that divides X by Y. Yes, that’s right, divide by zero!
 Save the Business Object and run the page. An exception should occur and the following message should appear:

Figure 104: Divide by Zero Message
 Now add a Recover stage, a Resume stage, and another End stage and link them up as shown below. Run again to see the effect.

Figure 105: Recover and Resume Stages
Rather than fail at the Calculation stage, the exception has been recovered. Critically, the flow of the page has jumped between two stages (Calc1 and Recover1) that are not connected by a physical link.
The Recover stage attracts, or catches the exception, giving the designer (i.e., you) the opportunity to create some sort of recovery sequence. In this basic example, the recovery sequence is simply to take the diagram to a different end point.
When an exception is caught, the Business Object (or Process) is said to be in Recovery Mode, meaning the exception is “live”. Passing through the Resume stage diffuses the exception and enables the diagram to come out of Recovery Mode and continue a normal flow. Importantly, the Resume stage does not fix anything - that is the responsibility of the designer.
Key Points
 A Recover stage acts like a magnet – exceptions are drawn to it and the diagram flow will jump from the exception point to the Reco