Try-Catch

Name

Contains the name of the step.

Try

Specify an action to perform. If an exception is expected as a result of an action, specify the exception in the Catch block.

Exceptions

Specify one or more exceptions you expect to catch.

Each Catch branch consists of a list of exceptions and, to the right of that, the action to perform if execution of the Try branch throws one of these exceptions.

Each exception is given a name, corresponding to the exception name used in a Throw step or a predefined exception name.

When an exception is added or edited in a Catch branch, the editor proposes those exceptions that may be thrown inside the Try branch and which are not yet listed in a Catch branch.

Finally

Specifies the action to perform just before leaving the Try-Catch step.

Execution of the Try-Catch step can be a bit more complex than other steps. The most common execution cases are the simplest and explained first. The most complex cases appear when the Finally branch contains steps (is not empty).

In all cases, execution of the Try-Catch step begins by executing the Try branch. This can end normally, or by an exception thrown by one of its steps.

Most common cases: Finally branch is empty

Try branch ends normally

Execution proceeds with the step after the entire Try-Catch step. That is, the Catch branches are not executed in this case.

Try branch ends with an exception thrown

From the step that throws an exception, execution proceeds directly to the beginning of the Catch branch that lists the exception.

More complex cases: Finally branch is empty

Try branch ends with an exception thrown, but no Catch branch lists that exception

This case is treated as if the Try-Catch step itself throws the exception, which is handled the same way as when any other step throws an exception. All cases listed here apply.

This strategy ("treated as if the Try-Catch step itself throws an exception") is used in many other cases.

If all Try-Catch steps have empty Finally branches, the workflow logic searches for a matching Catch branch in the surrounding Try-Catch steps that contain Try branches with this Try-Catch step. If such a Catch branch cannot be found in any surrounding Try-Catch step, the exception is set to "not handled" within the workflow. In such a case, execution of the Robot workflow as well as the containing Call Robot step stops, and the error is handled as specified on the Error Handling tab of the Call Robot step.

If any Try-Catch step also has a Finally branch, the execution is similar, but with executing one "throw" at a time.

Try branch ends by an exception thrown and the appropriate Catch branch does the same

The exception thrown in the Catch branch is not handled by the Catch branches in the same Try-Catch step. Instead, this is treated as if the Try-Catch step itself throws that exception. The details are as described in the previous case.

A note on nested Try-Catch steps

An exception that is handled by a Try-Catch step is not handled by a surrounding Try-Catch step. Once the Catch branch that can handle the exception is found, the exception is considered fully handled and is "forgotten." Execution of the Catch branch starts and proceeds in the normal way. Thus, each exception is handled only once.

Most complex cases: Finally branch is not empty

In these cases, the steps in the Finally branch are executed just before execution leaves the Try-Catch step, no matter how the execution goes. The following cases show how this works out in detail for each of the cases discussed above.

Try branch ends normally

Execution proceeds with the steps in the Finally branch. What happens afterwards depends on how execution of the Finally branch ends.

• If execution of the Finally branch ends normally, execution proceeds with the step after the entire Try-Catch step.

• If an exception is thrown during execution of the Finally branch, it is treated as if the Try-Catch step itself throws that exception.

Try branch ends with an exception thrown and the Catch branch ends normally

After executing of the Catch branch, the logic is exactly as in the previous case.

Try branch ends with an exception thrown, but no Catch branch lists that exception

In this case the exception is "remembered" and execution proceeds with the steps in the Finally branch. What happens afterwards depends on how execution of the Finally branch ends.

• If execution of the Finally branch ends normally, execution proceeds as if the Try-Catch step itself throws the "remembered" exception again.

• If an exception is thrown during the execution of the Finally branch, it is not handled by the Catch branches in the same Try-Catch step. Instead, this is treated as if the Try-Catch step itself throws that exception (that is, the exception that was thrown by the Finally branch). The "remembered" exception is effectively "forgotten" at this point.

Try branch ends with an exception thrown and the appropriate Catch branch does the same

This is handled as in the previous case, except that the "remembered" exception is the one thrown by the Catch branch rather than the one thrown by the Try branch. As shown above, the exception thrown by the Try branch is fully handled and "forgotten" at the moment when execution of the Catch branch begins.

When a step encounters an error during execution, it throws one of the following exceptions. These exceptions can also be thrown explicitly by Throw steps if needed.

When thrown because of step errors, the predefined exceptions include a message explaining the issue. This message is made available if the exception is not handled by a Try-Catch step in the Robot workflow, but instead terminates the execution of the Call Robot step .

All "internal" exceptions are predefined, and their names cannot be changed. The name of a "User-defined" exception can be changed by the user, depending on what step the timeout refers to. For example, it can be changed to InputNameTimeOut or LoginTimeOut.

• TimeOutError: Thrown if the execution times out.
• FinderIssue: Thrown if a finder fails to find an element.
• DeviceIssue: Thrown if a problem on a device or a driver that prevents the execution of a step.
• IncorrectValueIssue: Thrown if the value of an expression is not suitable where it is used, such as -1 in "one".substring(-1).
• ExtractIssue: Thrown if the Extract step fails to extract anything.
• DivisionByZeroIssue: Thrown if a division by zero (or modulo by zero) occurs during the evaluation of an expression.
• OverFlowIssue: Thrown if an overflow occurs in the evaluation of an expression.
• ConversionIssue: Thrown if during the evaluation of an expression a conversion from one type to another fails, such as "one".integer().
• DisappearedIssue: Thrown if an action fails to find the component or the application upon which the action has to perform.

Whenever an expression is a part of a step, execution of the step can throw the following exceptions:

• IncorrectValueIssue

• DivisionByZeroIssue

• OverflowIssue

• ConversionIssue

The following table lists exceptions that can be thrown by steps, finders and other workflow elements. Expression issues are any of the issues thrown by the steps with expressions.

The Guarded Choice step may throw the following exceptions, depending on the guards used in the step: