A robot may use different approaches in different cases. The cases may be distinguished either based on explicit tests; 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 (such as the presence of a particular tag in an HTML page). Error handling is about changing the flow of execution when particular errors occur (for example, some anchor tag is not found on the HTML page as expected and cannot be clicked). Often a situation can be seen both ways: An anchor tag should be clicked if found (this is a condition), or the robot can try and click it to 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, try and load the page and treat any error as an indication that the condition failed.

Other errors are signs of genuine problems with the robot or the website being accessed. For example, the website 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. 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, you can configure 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 applied as if an error occurred.

For each step in the robot, you can configure the desired reaction to errors. Two useful error handling options are described here; see How to Handle Errors for information on the other options. The first option 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 handles based on the Try Next Alternative option. Consider the following robot 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 does not continue at the following step, but instead at the beginning of the next branch going out from the Try step.

Each branch 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 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.

As with ordinary programming languages such as Java, JavaScript, C# or similar, the preceding 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 is to 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.