Exception Handling

Whenever something unexpectedly goes wrong during the execution of a task, an exception is raised. When creating a task in Mail & Deploy, you can control how these exceptions will be handled.

Example: You have set up a task that distributes a report document by e-mail (see Distribute by E-Mail Action). If the e-mail server is not reachable during the execution of the task, an exception will be raised.


In order to understand how exceptions are handled in Mail & Deploy, it is important to understand the hierarchical structure of tasks; all actions within a task are organized in a hierarchy that consists of Action Containers and Actions. These are organized in hierarchies like the following:

ACTION CONTAINER #1
ACTION #1.1
ACTION #1.2 
ACTION CONTAINER #1.3 
ACTION #1.3.1 
ACTION #1.3.2 
ACTION #1.3.3

Any exception that occurs during the execution of an action will be passed on to the parent action container of that action. Each action container has an Exception Behaviour attribute that dictates how an exception shall be handled; the available behaviours depend on the type of action container, but generally speaking there are two main ways to react to an exception:

  • The action container refuses to handle the exception; in that case, that exception will be passed on the the parent action container.
  • The action container handles the exception; in that case, the action container will do what the Exception Behaviour dictates and the exception will then be dismissed and will not affect the remainder of the execution.
Example: Let's have look at the action hierarchy depicted above; if an exception occurs in Action #1.3.2 it will be passed on to Action Container #1.3, because that is the parent action container of Action #1.3.2. Let's suppose the exception behaviour of Action Container #1.3 is set to "Continue with next Action"; in that case, the action container will dismiss the exception and simply continue with the execution of Aciton #1.3.3. If, however, the exception behaviour of Action Container #1.3 is set to "Do Not Handle", then the exception will not be handled at all; instead, the exception will be passed on to Action Container #1, which will have an exception behaviour of its own that will control how that exception will be handled.

If an exception has reached the task itself which means that either a direct sub-action of the task has raised the exception or that all action containers have not handled the exception -, the exception cannot be passed on to a parent action container, because the task is already the top container of the hierarchy. In that case, the exception behaviour of the task dictates whether the task execution will be regarded as successful, cancelled, or failed; the logic behind this determination is as follows:

  • If no exception occurs during the execution of a task, the execution of the task will be regarded as Successful.
  • If an exception occurs during the execution of a task and that exception is not handled by any action container within the task and the task has an exception behaviour of Do Not Handle, the execution of the task will be regarded as Failed.
  • If an exception occurs during the execution of a task and that exception is not handled by any action container within the task and the task has an exception behaviour of Cancel Task, the execution of the task will be regarded as Cancelled.
  • If an exception occurs during the execution of a task and that exception is either handled by an action container within the task or it's passed on the task and the task has an exception behaviour of Continue With Next Action, the task will simply continue the execution and the execution of the task will be regarded as Successful.


Examples

The following examples will demonstrate how exception handling works in several scenarios.

Example 1 

Let's suppose we have set up the following task:

TASK (Exception Behaviour=Do Not Handle)
FILTER DATASOURCE FIELD ACTION 
CYCLE (Exception Behaviour=Do Not Handle) 
CREATE REPORT DOCUMENT ACTION 
SAVE REPORT DOCUMENT TO FILE SYSTEM ACTION 
END CYCLE

Let's suppose the an exception occurs when saving the report document to the file system, which is the last sub-action of the cycle action container. That exception will be passed on to the parent action container of the current action; and that is the cycle. The cycle has an exception behaviour of Do Not Handle, which means that the cycle does not handle the exception at all and passes it on to its parent action container. The parent action container of the cycle is the task and has an exception behaviour of Do Not Handle. That means that the task execution will immediately stop and the execution will be regarded as Failed, because an exception has occurred and has not been handled by any action container.


Example 2 

Let's suppose we have set up the following task:

TASK (Exception Behaviour=Do Not Handle) 
FILTER DATASOURCE FIELD ACTION 
CYCLE (Exception Behaviour=Continue With Next Action)
CREATE REPORT DOCUMENT ACTION 
SAVE REPORT DOCUMENT TO FILE SYSTEM ACTION 
END CYCLE

Let's suppose the an exception occurs when creating the report document, which is the first subaction of the cycle action container. That exception will be passed on to the parent action container of the current action; and that is the cycle. The cycle has an exception behaviour of Continue With Next Action, which means that the cycle will simply continue with the next action after the one that has raised the exception; in other words: the cycle will continue with the execution of the action that saves a report document to the file system. If the task then completes, its execution will be regarded as Successful.


Example 3 

Let's suppose we have set up the following task:

TASK (Exception Behaviour=Cancel Task) 
FILTER DATASOURCE FIELD ACTION
CYCLE (Exception Behaviour=Do Not Handle) 
CREATE REPORT DOCUMENT ACTION 
SAVE REPORT DOCUMENT TO FILE SYSTEM ACTION 
END CYCLE

Let's suppose the an exception occurs when creating the report document, which is the first subaction of the cycle action container. That exception will be passed on to the parent action container of the current action; and that is the cycle. The cycle has an exception behaviour of Do Not Handle, which means that the cycle does not handle the exception at all and passes it on to its parent action container. The parent action container of the cycle is the task and has an exception behaviour of Cancel Task, which means that the execution of the task will immediately be stopped and will be regarded as Cancelled.

Example 4 

Let's suppose we have set up the following task:

TASK (Exception Behaviour=Continue With Next Action) 
FILTER DATASOURCE FIELD ACTION 
CYCLE (Exception Behaviour=Do Not Handle) 
CREATE REPORT DOCUMENT ACTION 
SAVE REPORT DOCUMENT TO FILE SYSTEM ACTION 
END CYCLE 
DISTRIBUTE BY E-MAIL

Let's suppose the exception occurs when creating the report document, which is the first subaction of the cycle action container. That exception will be passed on to the parent action container of the current action, and that is the cycle. The cycle has an exception behaviour of Do Not Handle, which means that the cycle does not handle the exception at all and passes it on to its parent action container. The parent action container of the cycle is the task and has an exception behaviour of Continue With Next Action, which means that the execution will continue with the action that distributes by e-mail because that is the next action after the one from which the exception has been passed on (e.g. the next action after the cycle). The execution of the task then continues and if it completes, will be regarded as Successful.


T
Team is the author of this solution article.

Did you find it helpful? Yes No

Send feedback
Sorry we couldn't be helpful. Help us improve this article with your feedback.