Exception Handling Best Practices

Overview

An Exception is an unexpected anomaly that can occur at runtime. Exceptions typically occur when the function of a Designer Element is unable to proceed as intended. A common example of an Exception happens when a step has incorrect Data Mapping. This means that if a step is expecting an Int32 input value, an unexpected String value will cease the function of the step, rendering an Exception Message with information about the error. These Exceptions will happen automatically without configuration.

Exceptions can also occur after steps in a Flow. These allow for more customization if an error is reached that the user wants to be handled differently at runtime. This practice is used to anticipate errors or trigger customized errors for effective management. The available Exception Handling tools act as a safety net for an application at runtime to appropriately inform users of an occurrence and record the traces. 

Every step in a Flow has the option to enable an On Exception Outcome path, which can lead to other steps that will help with recording logs or handling the data differently if an Exception occurs. The Catch Exception step can be used for the same purpose, except this step will automatically trigger when any Exception is first detected in the Flow. This form of Exception Handling does not need to be configured for every step because Decisions will capture functional exceptions regardless and record them to the back-end log files. 

Default Exception Example

In the example below, an Add step was added to a Flow with no input values specified. When the Debugger runs, an Exception occurs automatically. The details of the Exception (as shown in the Debugger) indicate that the step has no values to perform the intended function and that the error was delivered.

Catch Exception Step

The Catch Exception step is responsible for catching Exceptions immediately as they occur in the Flow. In the screenshot below is a Flow with two Add steps, both of which are expected to throw an error at runtime. 

In the example on the left, the Flow halts the Debugger at the first Add step that throws an Exception Error, then the error details are sent to the Catch Exception step. Because the step was broken at runtime, the Flow does not continue after the step that provided the error. The path of the Catch Exception step will continue since it was triggered when the Exception occurred in the Flow.

In the example on the right, the Add steps are reached at the exact same time when the Flow is executed. Again, the Flow is halted since neither function can be completed and the error details of both steps are received by the Catch Exception step since both occurred at the same time. 

The Catch Exception step typically leads to other Exception Handling steps, then to its own separate End step. In this below example, a Log step is added after the Catch Exception step to simulate one of the most commonly used steps for Exception Handling. Exception Handling processes that are comprised of several steps are best-suited when compartmentalized as a Sub Flow, then the Sub Flow with the Exception Handling process can be referenced anywhere in the project. 

When the Debugger executes the Flow, the Catch Exception step Output is used to map the Input of the Log step. The Log step is configured to take the Exception Message, Stack, Full Trace, and Step Name from the Catch Exception step and record it to the back-end log files.

The Catch Exception step can also be observed outside of the Debugger in the Decisions Studio. In the GIF below, the Flow is executed using the Catch Exception step in the Flow Designer. When Catch Exception is used, the Flow continues to run as expected on the front-end despite the error occurring from the Add step (because it was logged using Exception Handling on the back-end). When the Exception Handling steps are removed from the Flow, the Flow Run Error window appears immediately at runtime, as opposed to discretely ending the Flow and recording the errors.

In a more advanced use case, an Exception Handling process could contain steps that log the error, alert or send a task to a user, evaluate the error data against Rules, and much more. Because of this, Sub Flow compartmentalization becomes an excellent tool for maintaining these processes.

On Exception Outcome Path

In the Flow Designer, steps have the ability to enable an On Exception outcome path from the Properties tab of the step. This outcome path works the same way as a Catch Exception step, except it is specific to the enabled step.

Select a step and navigate to the OUTCOMES category on the Properties panel. Select the checkbox for the Add Outcome for Exception option. When the box is enabled, a new outcome path for the step will appear. Exception handling steps can follow on this outcome path, similar to the examples above. When the Flow is executed using the On Exception outcome path, that path will be followed when the Exception Error is reached at runtime.