Exception Handling Best Practices

Overview

An exception is an unexpected anomaly that can occur within a Designer Element 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 be triggered after steps in a Flow, which allows for more customization if an error is reached that the organization wants handled differently at runtime. This practice is used to anticipate errors or trigger customized errors for effective management. The exception handling tools in Decisions 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 the logs or handling the data differently if an exception occurs on the enabled step. 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. To learn more about what kind of errors Decisions logs by default and how these settings can be changed, please visit the Logging Settings article.

Default Exception Example

In the example below, a step is added to a Flow and the input values for this step are left undefined. 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, thus the error was delivered. 

Exception errors recorded to the Primary Log file by default. The log files are located at C:\Program Files\Decisions\Decisions Services Manager\Logs in the PC File Explorer. In the screenshot below, the Primary Log is located and opened in Notepad, where the recorded error from the example above can be viewed without the entire stack trace. 

Catch Exception Step

The Catch Exception step is responsible for catching exceptions immediately as they occur in the Flow. In the screenshot below, the screenshot below has 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 in the debugger at the first Add step that throws an exception error, then the error details are sent to the Catch Exception step. The Flow does not continue after the step that gave the error, since the function of that step is broken in this runtime session. 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 complete 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 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 behavior of using the Catch Exception step can also be observed outside of the debugger. In the capture below, the Flow is executed using the Catch Exception step at first. When Catch Exception is used, the Flow continues to run as expected on the front-end despite the error occurring with 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 exception error 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 task a user, evaluate error data against rules, and much more. Because of this, the 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 selected 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 section of the properties, then use the Add Outcome for Exception box. 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.