Error Handling

Error Handling is configured using the following properties.

API Exception

This property specifies whether to report the incident back to the caller of the robot. Reporting works differently depending on how the robot is executed:

• The property has no effect when the robot is executed in Design Mode in Design Studio because the incident always is reported in this mode (except when it is handled using Ignore and Continue as described below).
• When the robot is run in the Management Console, API exceptions are just counted and logged as errors and do not stop the execution. In this scenario, we recommend using the same value (checked or unchecked) as for Log as Error.
• When the robot is executed by a client via one of the APIs and runs on a RoboServer, the report is sent back to the caller via the API as follows:

  RobotErrorResponse

  This causes an exception at the caller side, at least when using the default RQLHandler. (This case explains the name of the property.)

The property may be unchecked or checked, but may also be marked with an asterisk * meaning that it has been explicitly set to a non-default value. This is explained in Show Changes from Default, where it is also shown how to remove the asterisk and revert to the default value. When the default value applies (that is, when no asterisk is present), be aware that the default varies according to the selection made under the Then property.

Log as Error

This property specifies whether to log the incident. This differs from reporting (see the preceding).

• When the robot is executed in Design Mode in Design Studio, the incident is added to the log that is displayed when you select View Log in the View menu.
• When the robot is executed in Debug Mode, the incident is added to the Log tab.
• When the robot is run in a RoboServer (from the Management Console or via the API), the incident is logged in the place defined in the cluster settings for the given RoboServer. This is most likely the same database that the Management Console uses.

The property may be unchecked or checked, but may also be marked with an asterisk * exactly as explained earlier for API Exception.

Then

This property specifies how and where to continue execution of the robot after the incident. The following options are available.

Skip Following Steps (Default)

The steps following the one with the error (or failed test condition) are not executed. Execution otherwise proceeds as if they had been executed successfully.

Ignore and Continue

The step with the error (or failed test condition) is skipped, and execution continues with the following step as usual.

Try Next Alternative

This can be used in a branch coming out of a Try step. Execution of the current branch from the Try step is abandoned and execution continues with the first step on the next branch from that Try step. Execution will continue there with the same robot state as for the first branch.

If the current branch is the last one from that Try step, Try Next Alternative is not illegal, but results in an error ("all alternatives failed") which is handled according to the way error handling is configured for the Try step.

When Try steps are nested, it is possible to select the relevant Try step among those that are on the execution path to the current step.

Send Backwards (legacy)

This option is present only to provide backwards compatibility with robots created by Design Studio versions prior to 8.0. It is described separately.

Next Iteration

This can be used within a loop, that is, following a loop step of some kind (except a Repeat-Next loop). Execution of the current loop iteration is abandoned and execution continues with the next iteration. That is, execution continues with the first step after the loop step, and with a robot state that corresponds to the next looped-over item.

When loops are nested, it is possible to select the relevant loop in which to go to the next iteration.

Break Loop

This can be used within a loop, that is, following a loop step of some kind (including a Repeat-Next loop). Execution of the loop is abandoned. Thus the current iteration is not finished, and subsequent iterations are not executed at all. This means that execution continues with the same step as after normal termination of the loop.

When loops are nested, it is possible to select the relevant loop among those that are on the execution path to the current step.