Catching All Unhandled Exceptions
- Updated on 09 May 2013
- 4 minutes to read
An exception is an anomalous or unexpected situation in a flow that requires special steps to handle it. In other words, it usually means something went wrong in your flow. Using e xception handling is a way to anticipate errors and manage them effectively. Think of exception handling as a safety net for your flows - it can save information or alert the user that something is wrong. Exception handling is important for maintaining a good experience for users who use your flow.
The Decisions platform provides two ways to handle exceptions: an outcome path called On Exception which catches exceptions from a given step, and a step called Catch Exception which can handle any exception that happens in a given flow. The On Exception outcome path can be activated by selecting the Add Outcome for Exception checkbox in the Properties panel of a given step. The Catch Exception step can be activated by dragging it onto the workspace from the Steps tab on the right in the Flow Designer.
Our example flow will illustrate how to use two exception handling tools - the On Exception outcome and the Catch Exception step. We begin with a simple flow that sends an email. (For more information on creating a flow, see Creating Your First Flow .)
To guarantee an exception, we've intentionally set the mapping type of the From property to "Ignore."
When we run our flow in the debugger, the expected error in Send Mail 1 prevents our flow from finishing. (For more information on running a flow in the debugger, see Using The Flow Debugger .)
Instead of failing whenever Send Mail 1 produces an exception, direct the flow to a second End Step . In a production scenario, we would direct our flow through more complex steps to display our errors or create logs entries from them. But for simplicity in our example, we will simply end the flow.
Locate the End step component in the Toolbox panel, under the category Flow Management . To distinguish it from the End Step that already exists, name it "No Error."
Next, configure our flow to go to No Error whenever Send Mail 1 produces an exception. To do this, select Send Mail 1 and, in the Properties panel, select the Add Outcome for Exception checkbox under the Outcomes section.
Now, that Send Mail 1 has a path for On Exception , connect it to No Error .
When we run our flow in the debugger, the exception produced by Send Mail 1 causes our flow to follow the On Exception path and finish at No Error . Because we've handled the exception that Send Mail 1 produced, our flow reports no errors.
For simple flows, On Exception paths are a quick and simple solution to the problem of exception handling. When flows become large or complex, however, the number of On Exception paths required can complicate design and make changes difficult. To alleviate this problem, the Catch Exception component listens to all of the steps in a flow and handles their exceptions in a uniform manner.
Begin implementing the Catch Exception component by removing the On Exception path connecting Send Mail 1 to No Error . Click on the Send Email 1 step, and uncheck the Add Outcome for Exception checkbox in the Properties panel. This saves our flow from reporting a validation error and is the last step before saving and testing our flow in the debugger.
Next, drag Catch Exception to our workspace. It can be found in the Toolbox panel, under the category Flow Management .
Catch Exception 1 has a single outcome - On Exception - to connect to No Error .
In the debugger, we can see that the exception produced by Send Mail 1 is caught by Catch Exception 1 , despite there being no path drawn between them. With this arrangement, our flow could have as many steps as we wanted. Every exception thrown would be caught by Catch Exception 1 and handled in the same manner (see the production scenario example below).
Additionally, in the debugger if we click Catch Exception > View Output Data, we canview the precise details of the exception that occurred. These details can be displayed or logged with additional steps discussed elsewhere.
It is best practice to include at a minimum, a Catch Exception step, and a form to show to a user that says an error has occurred. (This assumes a flow that has user interaction.) The Error Handling Flow below is a Start Linked Flow Async step. This type of step simply initiates another flow (in this case, a standard error handling flow that tasks an administrator to look into the error), but does not wait for that flow to complete. The process moves on to the End step regardless of the status of the Error Handling flow. It is also best practice to use this type of flow linking so the parent "calling" process does not keep running.