Exception handling scope

An IBM Robotic Process Automation script is an optional set of subroutines inside the main routine. Although variables always have global scope, exception handling takes place on the scope of the subroutine the Handle Error (onError) command is called. This section details the Handle Error (onError) command's function inside subroutines.

When you start a blank wal script in IBM RPA Studio, you start at the main routine. The Bot Runtime, the runtime environment that runs the script, runs commands from the main routine starting from line 1. Variable and subroutine declarations are also in the main routine.

The scope of the main routine encompass other subroutines if you call them with the command Run Subroutine (goSub), Run Subroutine If (goSubIf), or Execute Subroutines (goSubs). The following image shows the Call Graph tab from IBM RPA Studio of a script with four subroutines. There are highlights for better visualization of the subroutines' scope.

The scope1 rectangle demarks the main routine scope. The scope5 rectangle demarks subroutine sub1's scope. The scope2 rectangle demarks sub2's scope. The scope3 demarks sub3's scope. The scope4 rectangle demarks sub4's scope.

Notice that subroutines sub1, sub2, and sub3 are under the main routine's scope, but sub4 is not. This happens because the script does not run subroutine sub4 with one of the three commands mentioned before; the script only instantiates sub4 without calling it. The Call Graph is useful to analyze the script's subroutines scope.

The Handle Error (onError) command watches for Runtime Exceptions in the subroutine scope where you call the command and the subroutine's inner scopes. The command will watch for raised Runtime Exceptions from the moment the command runs until:

• The end of the innermost subroutine scope
• The appearance of a new Handle Error (onError) command call

When Handle Error (onError) catches a Runtime Exception raised by a command, you can configure one of two exclusive actions to take place:

• Ignore the exception and call the following command after the command that raised the exception.
• Call an exception handling subroutine.

The following image shows the same script, now with an exception handler subroutine attached to sub2's scope. This attachment happens because of a Handle Error (onError) call in the sub2 subroutine.

The Handle Error (onError) watches for Runtime Exceptions events from the moment he runs in the sub2 subroutine until the end of the innermost scope inside sub2's scope. In other words, sub2_except_handler, the exception handling subroutine, executes whenever a Runtime Exception event raises in sub2 or sub3.

The exception handling subroutine acts like any other subroutine. It has commands to perform actions in the automation context. However, the exception handling subroutine has one requirement you need to consider: the exception handling subroutine needs to handle the exception.

When the exception handling subroutine ends, the Bot Runtime interpreter evaluates if the exception handling subroutine handled the Runtime Exception. You can handle the exception in one of two possible ways:

• By stopping the bot's runtime with the Stop Execution (stopExecution) command.
• By calling the next command after the command that raised the exception with the Recover from Error (recover) command.

Important: Failing to end the exception handling subroutine with a command to handle the exception will result in a Runtime Exception event by the Bot Runtime.