Error Handling

This lesson is part of the course UiPath Automation Coding Standards . Use navigation on the left.

UiPath employs an exception handling mechanism very similar to what modern programming languages permit. It is mainly focused on the Try Catch activity and, together with the Throw activity, it enables an elegant error handling mechanism.

Two types of exceptions may happen when running an automated process: somewhat predictable or totally unexpected. Based on this distinction there are two ways of addressing exceptions, either by explicit actions executed automatically within the workflow, or by escalating the issue to a higher level.

Exception propagation can be controlled by placing susceptible code inside Try Catch blocks where situations can be appropriately handled. At the highest level, the main process diagram must define broad corrective measures to address all generic exceptions and to ensure system integrity. The REFrameWork has this exception handling mechanism in place and will recover from any unexpected error.

Contextual handlers offer more flexibility for Robots to adapt to various situations and they should be used for implementing alternative techniques, cleanup or customization of user/log messages. If a block catches an exception it cannot handle, it is recommended to log the exception and then rethrow the exception to the higher invoking level. Take advantage of the vertical propagation mechanism of exceptions to avoid duplicate handlers in catch sections by moving the handler up some levels where it may cover all exceptions in a single place. In the REFrameWork this is the place is the Main.xaml workflow file.

Enough details should be provided in the exception message for a human to understand it and take the necessary actions. The exception message and source are essential. The source property of an Exception object will indicate the name of the activity that failed (within an invoked workflow). Again, naming is vital – a poor naming will give no clear indication about the component that crashed or about the source of the problem.

Try Catch

Any activity that may throw an exception should be part of the Try block in a Try Catch activity. It is not necessary to be directly in the Try, there can be stand alone component that is not handling exceptions (no Try Catch in it), but, when invoking it, it should be placed in the Try block. There is only one exception from this rule: To set the status of a job as “Faulted” in the Orchestrator in the case of an unattended robot, the Main file must end with an exception, i.e. it should not finish the execution succesfully. This only applies when the job is triggered from Orchestrator, otherwise the exception message popup is displayed on the screen. In this case there might be some logic to throw an exception in the Main file if the job is considered to be failed. In the REFrameWork, in the End Process state we have a Throw activity in case there’s a fatal error – like failing to initialize.

There can be multiple Catches and, in case of an exception, only the most specific Exception will be caught and its handler executed. If the exception that is thrown in the Catch is not contained in any of the defined catches, the exception will not be caught and will propagate upwards. The Finally block will execute when the execution leaves the Try and the Catches block.

Consider the following scenarios:

Click to enlarge
  1. In the first case PathTooLongException is thrown, so the catch that executes is PathTooLongException as it is the exact match (most specific). Assuming no exception is thrown in the catch, the Finally block will execute.
  2. IO.FileNotFoundException is thrown, and the catch block executed is the IOException as FileNotFoundException inherits from the IOException class, so it is the most specific.
  3. SelectorNotFoundException is thrown, and the most generic System.Exception executes. In fact, System.Exception will catch all exceptions, including custom defined ones. After that, the Finally block executes.
  4. SelectorNotFoundException is thrown, but there is no Catch that can handle this exception. The exception is propagated upwards and Finally does not execute.

Despite their usefulness, do not overuse the Try Catch activity. You should not catch an exception unless you have a good reason for it. In most cases, the Catch will handle the exception and recover from the error. There are some cases however when an exception is caught to perform some actions (like logging) and then the exception is rethrown to the upper levels. This is a standard mechanism in the Workblock components of the Enhanced REFrameWork.

Throw

The Throw activity is used when the intended action is to throw an exception. This activity takes an exception object input argument which can be created inline.

Another effect of using the Try Catch activity together with Throw is the reduction of decisions (If statements), as well as the subsequent increase of readability. This is because of the assumption that the code placed after the Try Catch activity will only be executed if no exception was triggered.

Rethrow

In some cases, it may be necessary to return the exception to the normal flow by using the Rethrow activity. This activity can only be used inside the Catch block of a Try Catch activity and, as it does not receive any input, it uses the same exception that the Catch block caught.

A common use for Rethrow is when catching an exception for a particular action (for example, logging) and rethrowing it for processing in upper levels.

Business Rule Exception

Business Rule exceptions can occur when an aspect of the process being automated does not follow the expected flow (for example, a Robot needs to download an invoice from an email, but the email has no attachments).

Differently from Application Exceptions, retrying Business Rule Exceptions automatically would not be a good idea, since they usually depend on some external action in order to be successful (for example, the invoice needs to be attached and the email resent). For this reason, the Orchestrator does not automatically retry transactions that failed due to a Business Rule exception. For more information, refer to the Orchestrator Guide.

Retry Scope

The Retry Scope activity provides away to try a block for a predefined number of times in case there are any exceptions or a particular condition is not met. An important aspect of the Retry Scope activity is that it reattempts to execute its contents without ending the workflow. In addition, it does not throw exceptions unless the number of retries is reached. When checking whether a particular condition is met, the activities IsTrue and IsFalse can be used in the Condition block.

This activity is a powerful tool in cases where exceptions are thrown sporadically and other measures, like tuning selectors, already took place. For example, a particular selector is not found in a certain applications in less than 5% of the times the workflow runs, but no further selector improvements are possible. Using Retry Scope in this scenario will make the robot try to access the selector again in case a SelectorNotFoundException is thrown.

You might be interested in the following courses:

Course Category

  • UiPath Automation Coding Standards

    by Ajay Kumar Konda

    Coding standards are a collection of rules, guidelines, and best practices. Coding standards are important for safety, security, and reliability. In this course, we learn the most important and UiPath recommended coding standards. Starting from naming conventions to maintaining your code in the code repository, we cover all the best practices.

  • Automation Anywhere Bot Development Best Practices

    by Ajay Kumar Konda

    This is an advanced guide to best practices that need to be followed in developing bots using Automation Anywhere. This course provides an introduction to common bot design guidelines and standards. Avoiding common mistakes and including these processes and considerations in your bot design standards, creates bots that are clean, easier to read, test, maintain, and are stable. Most of […]

  • All You Need To Know About Robotic Process Automation

    by Ajay Kumar Konda

    Robotic Process Automation(RPA) is a kind of automation where a bot performs human’s task in completing rules based jobs. Robotic Process Automation refers to a style of automation where a machine, or computer, mimics a human’s action in completing rules-based tasks. In traditional workflow automation tools, a software developer produces a list of actions to automate a task and interface to […]

Back to: UiPath Automation Coding Standards > Best Practices