In this example we will show how error handling can be used to select among several different alternative ways to achieve some goal. This relates to the discussion in Conditions and Error Handling, which also includes a tutorial video on the topic.
Suppose that some part of a web page has varying structure and layout, but always comes down to one of three cases. In each case there is some information we want to extract. This can be done by simply trying to do the extraction for one case at a time. If it fails, the next case is tried, until the third one, which we assume will succeed:
Note the ("Try Next Alternative") icons on the Extract steps, which mean that if extraction fails, the next branch from the Try step will be executed (if a branch coming out of a Try step succeeds, the next branch will not be executed). Thus the Extract steps do two things at the same time: They do some extraction from the web page, and if that cannot be done, they ensure that the next approach is tried. Please note that if any of the two steps on the first branch fails, the second branch is executed; this is an example of how the "success condition" for a branch may be expressed by a combination of steps.
This approach works best if the "third way" of extracting is bullet-proof (for example, by applying a fixed set of default values rather than actually extracting data from the web page). If the third branch accesses the web page like the first two branches do, it may not be wise to just assume that it will succeed. The next time the robot is run, the web site may have changed so much that none of the three strategies will succeed, and the robot should be able to respond to this in a reasonable manner.
This easiest way to respond is just report the problem back to the caller and log it, giving up on doing the extraction and whatever would follow it. This can be achieved simply by making the third branch inform the Try step if it fails to do its work, just like the first two branches:
Now if all three branches fail, the Try step will report and log the incident. This comes from the default configuration of error handling on the Try step:
(For a Try step, "Skip Following Steps" means that no additional action will be taken beyond reporting and logging.)
Alternatively, it is possible to make the Try step propagate the problem back to an earlier Try step for handling. We will explore this idea in the section on Try-Catch.