Errorhandler
Description
The Errorhandler data type represents the set of actions that should be executed if a Workflow command fails.
Attributes
| Attribute | Description | Required |
|---|---|---|
| quiet | Specifies if errorhandler should operate quietly. If this is set true, then messages regarding caught build exceptions will not be logged. | No. Defaults to false. |
Parameters specified as nested elements
command
A command type describes what command name to run. Only the command's name is a required attribute. The other attributes are ignored.
The example below shows how to specify to run a command named Recover
<command name="Recover"/>
arg
An arg tag describes the argument string to pass to the invoked command.
The example below shows how the errorhandler will emulate the following command invocation if an error occurs: ctl -m moduleX -c commandA -- -opt1 arg1 -opt2 arg2
<errorhandler>
<command name="commandA" module="moduleX/>
<arg line="-opt1 arg1 opt2 arg2"/>
</errorhandler>
An email element describes what command name to run. Only the command's name is a required attribute. The other attributes are ignored.
The example below shows how to specify to email a message to admin
<email to="admin@domain.com" from="user@domain.com"
subject="workflow encountered an error"/>
prompt
A prompt element describes that the command should take input from the user before proceeding. The message's string is a required attribute.
The example below shows how to prompt a user with a message
<prompt message="Continue? "/>
task
The errorhandler is also a TaskContainer and therefore, any task (or sequence) can be called.
The example below shows how to prompt a user with a message
<echo message="invoking defibrillator "/>
Examples
Shows errorhandler data type used in the workflow element.
<workflow name="Restart">
<errorhandler>
<email to="admin@domain.com" from="user@domain.com"
message="Restart failed"/>
<prompt message="Continue with Recover command?"/>
<command name="Recover"/>
</errorhandler>
<tasksequence>
<echo>running Stop command</echo>
<controller updateproperties="false">
<execute>
<context depot="${depot.name}"
entityClass="${context.type}"
entityName="${context.name}"/>
<command name="Stop"/>
</execute>
</controller>
<echo>running Start command</echo>
<controller updateproperties="false">
<execute>
<context depot="${depot.name}"
entityClass="${context.type}"
entityName="${context.name}"/>
<command name="Start"/>
</execute>
</controller>
</tasksequence>
</workflow>
This example shows a workflow called Start, that first checks to see if the service is already running and if the check fails, to call the startService command.
<workflow name="Start">
<errorhandler quiet="true">
<command name="startService"/>
</errorhandler>
<tasksequence>
<echo>running upService command</echo>
<controller updateproperties="false">
<execute>
<context depot="${depot.name}"
entityClass="${context.type}"
entityName="${context.name}"/>
<command name="upService"/>
</execute>
</controller>
</tasksequence>
</workflow>
This example shows a use of errorhandler in the apply-macro task.
<apply-macro name="doAction">
<errorhandler quiet="true">
<fail/>
</errorhandler>
<queryresults refid="deployments.query"/>
</apply-macro>



