RG-DBP-007 Try Catch Activity must catch explicit exception types
Description
RG-DBP-007 inspects the exception handling within a Robotic Enterprise Framework (or derivative) project.
The rule inspects non-framework workflows for Try Catch activities that catch the generic “System.Exception” exception type. This generic exception type should only be dealt with by Robotic Enterprise Framework workflows.
Impact
Breakage of Robotic Enterprise Framework transactional retry, notification and marking. Robot performance degradation by reliance on exception handling.
Mitigation
There are two types of exceptions that can be encountered when running a process:
1. Unexpected Exceptions
These are exceptions caused by external environmental conditions outside the control of the workflow code and are caught using the generic “System.Exception” exception type.
Catching the “System.Exception” exception type in your workflow prevents the Robotic Enterprise Framework from handling the exception and taking recovery actions.
The Robotic Enterprise Framework is designed to manage all unexpected exceptions.
- It takes system screenshots and logs the exception detail.
- It closes or kills each process application.
- It re-opens and logs in to each process application.
- It retries the processing of the current transaction.
2. Expected Exceptions
These are exceptions that could occur when workflow code performs a specific set of actions. For example, the “System.IO.FileNotFoundException” when writing to a file path or a “UiPath.Core.SelectorNotFoundException” when clicking a screen element.
By using the Try Catch activity and catching only the explicit expected exception types, a workflow can gracefully recover and continue the successful processing of a transaction without impacting the Robotic Enterprise Framework’s handling of unexpected exceptions. Even so, it is preferred that the developer perform checks to avoid the exception occuring rather than running into the exception and handling it with a catch. See Best Practice Exception Management section.
Best Practice Exception Management
Although a workflow can gracefully recover an expected exception, it is best practice to avoid an exception occurring.
This statement is driven by the high compute cost to generate an exception and its contained stack trace. A process that relies on the recovery of exceptions will have a higher compute cost to an identical process that avoids exceptions.
This increased compute cost translates into dollars when robots are hosted on virtual infrastructure services such as AWS or Azure. It also contributes towards longer handling times per transaction which compounds to a premature need to scale the robot footprint in high transactional cases.
Using the examples from above:
- the “System.IO.FileNotFoundException” could be avoided by checking if the file exists and creating it before attempting to write to it.
- the “UiPath.Core.SelectorNotFoundException” could be avoided by using an Element Exists or Find Element activity to confirm the state of the screen element before clicking it.
Exception management is best summarized as “Prevention is better than Cure”.