Error Handling

The area of error handling in robots has been thoroughly revised. The section How to Handle Errors explains this in detail; in the following we will merely indicate how the older way of error handling translates into the new one. In version 7.2, error handling was configured by way of the following properties:

All of this has been replaced by the following set of properties, which are explained below:

Errors May Be Reported or Logged No Matter How They Are Handled

It used to be that the step property "Own Errors" specified both whether to "report" an error and what effect the error should have on further execution of the robot (error handling). These aspects have now been separated and can be configured independently. Instead of "Own Errors" we now have three properties: "API Exception", "Log as Error" and "Then".

No matter how the error is handled (even if it is ignored), the incident can be reported back to the caller of the robot (this is named an "API Exception'). In addition and independently of this, the error can be logged ("Log as Error"). Both API exceptions and logging can be selected or deselected for each step independently.

The error handling aspect of the former "Own Errors" property is now taken care of by the "Then" property.

Errors Are Handled Where They Occur

Previously, one very important way to handle an error was to specify that it should be "sent backwards" (to a step further to the left in the robot) for handling. The configuration of "Received Errors" and "Branching Mode" on the (possibly many) traversed steps would then decide how the error would ultimately be handled. It might end up being "reported" (causing an API exception); affect the execution of the robot; or be ignored, and it was impossible to know without considering the configuration of all traversed steps.

This whole notion of "sending an error backwards" has now been replaced by a more direct approach, where you always specify on the step where the error occurs what to do with it, without depending on the configuration of other steps. Thus the "Received Errors" property has been removed.

When an old robot is opened, an analysis is done for each step that uses "Send Backwards" in order to determine how to assign the "Then" property. Most often, the result is that instead of "Send Backwards" (displayed as on the step), a step will now use either "Try Next Alternative" () or possibly "Skip Following Steps" () in combination with "API Exception" and "Log as Error".

"Send Backwards" is still available as a way to handle errors, but is deprecated (meaning you cannot select it when you edit the "Then" property). The only reason it is still available is that it is necessary in order to execute some robots in exactly the same way as in previous versions of Kapow Katalyst. It is needed only by a small number of robots. When examining these robots, you should think of all steps as having "Received Errors" set to "Send Backwards".

Small Changes to Robot Structure

In rare cases where branches merge, the result of the analysis described above may be that the step's "Then" property should be configured in different ways depending on the path followed to the step. In such cases, the step (and often small parts of the robot) will be duplicated to "de-merge" branches in a way so this dependency on the path disappears. Thus you may see some surprising expansion of the robot. The following robot is an example (it may seem contrived, but robots that exhibit this behavior are odd). The robot looked like this in version 7.2:

When step D is executed, it may report an error. If the step is reached on an execution path that goes via step B1, the error will be sent back to B1 and will be reported there. However, if step D is reached via step B2, it will not be reported. Rather, it will cause execution to proceed at step F.

When opened in version 8.0, the robot is automatically modified as follows:

We see that step D has been duplicated and that the two copies have been configured differently. The one associated with step B1 (in green) has "API Exception" and "Log as Error" turned on and uses "Skip Following Steps", while the one for B2 does no logging, but uses "Try Next Alternative". Step C has been duplicated also, in order to make it possible to connect the steps correctly.

Small Changes to the Order of Error Reports

It should be noted that in earlier Kapow Katalyst versions, "Send Backwards" made it possible to delay reporting an error as an API exception. In version 8.0, however, if an error is reported, it is reported as soon as it occurs. For some robots, this means that errors are reported back to the caller in a different order than previously, and they may be grouped into API exceptions in a different way, too.