Exception Handling Best Practices
  • 09 Dec 2020
  • 4 Minutes to read
  • Dark

Exception Handling Best Practices

  • Dark


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 the step are left undefined. When the Debugger runs, an Exception occurs automatically. The details of the Exception (as shown in the Debugger) indicating that the step has no values to perform the intended function and that the error was delivered. 

Exception Errors are recorded in the Primary Log file by default. The log files are located in the local PC's C:\Program Files\Decisions\Decisions Services Manager\Logs folder.
This file can be opened via Notepad, to view the recorded error from the example above 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 the Debugger at the first Add step that throws an Exception Error, then the error details are sent to the Catch Exception step. Due to the function of the step being 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 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. 

Using Sub Flows for Exception Handling
A Sub Flow is a Child Flow that is referenced from within a Parent Flow. For more information on Sub Flows and an example of what Exception Handling within a Sub Flow looks like, please visit the Using Sub Flows article.  

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's behavior 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 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 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, 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 its Properties tab, 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. 

Was this article helpful?