Catching All Unhandled Exceptions

Last Updated: 12/03/2015 Introduced in Verision: 2.0

An exception is an anomalous or exceptional situation in a flow requiring special processing. Exception handling is the response to this occurrence.

The platform provides two ways to catch exceptions. The On Exception outcome path catches exceptions from a single step, and can be activated by selecting the Add Outcome for Exception checkbox in the Properties panel. The Catch Exception component catches exceptions from all steps in a flow, and can be activated by dragging the Catch Exception component to the workspace from the Toolbox panel.


Our example flow will illustrate how to use two exception handling tools – an On Exception outcome and the Catch Exception component. We begin with a simple flow that sends an email.



To guarantee an error, 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.



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 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, we can select the On Exception outcome in the Events panel and view the precise details of the exception that occurred in the Data panel. These details can be displayed or logged with additional steps discussed elsewhere.


Production Scenario

It is best practice to include at a minimum, a Catch Exception step, and a form to present to a user stating an error has occurred (in processes that have user interaction). The Error Handling Flow in this example is a Start Linked Flow Async (or Fire and Forget Linked Flow) 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.

Additional Resources