¶ Exception
'Exception' is found in the 'Common' category of workflow nodes.
¶ What it does
The exception node provides a mechanism to handle unknown conditions that occur within other workflow nodes. These can be trapped errors or unexpected errors.
If an exception is thrown from within an exception state it is ignored.
¶ Typical uses
An Exception step can run its own code to carry out a desired error behaviour, for example, it may send an e-mail to give notification of a failed job.
Unless specific behaviour is programmed in, however, the errors will simply be added to the error log.
¶ How to use it
Exception nodes are the only state it is possible to move into where you don't need to join the lines in the configuration editor. When an exception node is entered a script is run, which can be used to carry out error behaviour, such as sending a failure email etc. The exception node is a queued node.
Without any additinal behaviour programmed in, the script for an Exception node looks like this:
// This script should exit with a result code that then gets mapped to the next state in the diagram
busby.exit(0)
There are three ways of transitioning into an exception node, as the default exception, as a linked exception and as a named exception.
¶ Default exception
If an JavaScript exception is thrown and there is nothing else to catch it, the default exception node will be called. This can happen by calling:
throw new Error("my new error")
... or if an unexpected error happens. Select the Default exception checkbox to set the exception as the Default exception.
¶ Linked exception
From a script step it is possible to link to a particular exception, as opposed to using the default exception. This is useful if there is particular error handling that is required for a certain step. To do this link the killed tag of the previous step to an exception node.
In this diagram the red tag of the script step is given the killed result code. Any exception in the script step will now go to the linked exception handler.
¶ Named exception
It is possible to set up multiple named exceptions, this is useful in a workflow where there are a number of different error handling conditions that might be used within a single workflow. For example it might be that some errors need to inform an engineering team, whereas others might need to inform an operational team. To cater for this it is possible to throw a named exception.
To do this use the busby.exception.throw call. This call asks for an error message, and then the name of an exception state to jump to. In the following snippet, the job would jump to the operational exception state.
busby.exception.throw("Something went wrong", "operational exception")
Detailed notes on the configuration editor can be found here
¶ How it works
Content >>>
Previous: Dispose || Next: File wait step
Index of: Workflow Nodes
Back to: Configuration Editor