Configuring Error Handling

Configuring error handling allows you to define the behavior when an execution fails. The main reason for implementing error handling is to prevent waiting tasks from starting when a prerequisite task fails.

For example, a sequence of Data Processing tasks representing a part of a life cycle of a transaction:

1. Enter transaction
2. Accept to FINAL
3. Early expire

If step 1 fails, step 2 and 3 will also fail and don’t have to be started.

Error handling is configured per node (task, group, test case) in the test plan Error Handling column, with the available options Stop, Continue and Default, where Default means use the Stop/Continue default setting of the node type.

Error handling of tasks

It is important to note that a task that fails will always stop running, the setting Stop/Continue defines what happens with the rest of the running sequence. Tasks that explicitly depend on other tasks, i.e. uses the output of another task, will fail unconditionally if the dependency task fails. Error handling configuration is important for implicit dependencies, where the dependency is defined only in the order of tasks.

Consider the example of entering a transaction and expiring it. The test case consists of three Data Processing tasks that implicitly depend on each other in a sequence:

Failing to enter a transaction it won’t be possible to accept nor expire it, so for step “1. Enter transaction” we can configure error handling to Stop, which will stop the sequence if an error occurs in the first step.

The same logic can be applied to step 2. Looking only at these three steps alone, it seems OK to continue if step 3 fails since it is the last step in this unit.

📘

Configure Error Handling to Stop for tasks that are critical to the rest of the sequence and Continue for tasks that are not.

Error handling of folders

Folder (group and test cases) nodes do not execute themselves and cannot fail by themselves. A folder node fails when one of its sub-nodes configured with Error Handling=Stop fails. A folder that fails because it receives and error from one of its sub-nodes will immediately stop all its sub-nodes from executing, but similarly to tasks the Stop/Continue setting defines if the sequence in which the folder executes should be stopped or continued.

Considering the early-expire example again in a little bit larger context:

1. When “A. Early Expire -> 1. Enter transaction” fails it will cause the test case “A. Early Expire” to fail, since the task has Error Handling = Stop.
2. Since the two test cases are logically separate “A. Early Expire” is configured with Error Handling = Continue.

Test cases that are independent and standalone (e.g. typical Unit Tests) can often be configured with Continue as the mode.

Configuring error handling defaults

Default error handling is configured in Settings -> Execution -> Error Handling Defaults.

The default settings allow you to configure default behavior per node type. The default setting will be used by any node in the test plan where Error Handling is set to Default.