Conditions and Error Handling

A robot may have to use different approaches in different cases. The cases may be distinguished either based on explicit tests, that is, by evaluation of conditions, or because errors occur and need to be handled.

Conditions change the flow of execution based on the content of the input robot state (e.g. the presence of a particular tag in an HTML page). Error handling is about changing the flow of execution when particular errors occur (e.g. some anchor tag is not found on the HTML page as expected and thus cannot be clicked). Often, however, a situation can be seen both ways: An anchor tag should be clicked if found (this is a condition), or the robot can just try and click it and handle the error (if it is not found). In some cases, what is commonly thought of as a condition is too complex to be written up as such, for example a condition saying "if this particular page can be loaded without error". In such a case, there is nothing to do but try and load the page and treat any error merely as an indication that the condition failed.

Other errors are signs of genuine problems with the robot or the web site being accessed. For example, the web site may be down and cause a page loading error, or a tag finder might fail to find a needed tag due to a dramatic page layout change of an HTML page. To sum up, a particular error may be considered a failed condition in some circumstances, and a genuine error in other circumstances. The interpretation depends on the robot.

Because of this blurred boundary between conditional execution and error handling, Design Studio provides both features in a unified way. For every step, it is configurable what to do in case an error occurs. Furthermore, steps with a test action (based on a condition of some sort) reuse the same approach, meaning that if the condition is not met, the (default) action is to do as if an error occurred.

For each step in the robot, you can configure the desired reaction to errors. We will describe two of the most useful error handling options here; see How to Handle Errors for information on the other options. The first to be described is closely linked to the Try step.

The Try step is similar to a branch point because it may have several branches going out from it. It differs from a branch point because branches beyond the first one are executed only if a step on the preceding branch encounters an error which it then handles by means of the option "Try Next Alternative". Consider the robot below and assume that each ordinary step is expected to output exactly one robot state:

The icon indicates that step B is configured to handle errors by "Trying Next Alternative".

If step B executes successfully, step execution is as follows: "A, T, B, C". Because the first branch going out from T executes without error, the second branch is not executed at all.

If, on the other hand, step B encounters an error, then the execution of steps is as follows: "A, T, B, T, D, E". After the error in step B is handled, execution will not continue at the following step, but instead at the beginning of the next branch going out from the Try step.

Each branch going out from a Try step represents one possible way to proceed from that point. Steps near the beginning of each branch probe if execution along the branch is a viable approach (and otherwise effect a "Try Next Alternative"), while later steps do the actual work when the branch turns out to be the right one for the case at hand. The probing steps near the beginning of a branch may be either test steps, or just any kind of steps that — if they encounter an error — indicate that this branch is not the way to proceed. There may be any number of such branches going out from a Try step.

Readers familiar with ordinary programming languages like Java, JavaScript, C# or similar will note how the above robot is similar to an "if-then-else" construct: The first branch after the Try step contains the condition (the "if" part) and the "then" part, while the last branch contains the "else" part. Should there be more than two branches, then the ones between the first and the last ones are like "else-if" parts.

If the first branch attempts to do some action that may error, the example can also be likened to a "try-catch" construct: The first branch is the "try" part, while the second branch is like the "catch" part.

Another error handling option, "Skip Following Steps" provides a more compact way of expressing a common special case, which is exemplified by the following robot. The step that can encounter an error is the first one on the first branch, and the second branch does nothing:

The effect of this is to simply skip execution of the steps after step B if it encounters an error. The same effect can be achieved without the Try step by using the error handling option "Skip Following Steps" (which is the default), in the following way: