November 23, 2016

Error handling on the Composite block level

Common practice in the engineering world is to combine different features or techniques in order to take advantage of all their strong points. In pSeven, there are blocks that support error handling, and there is a special block type - the composite block that is intended to contain other blocks. Now we have added the error handling support to composite blocks, which in fact enables error handling for any block contained in a composite.

Available error handling behavior settings in composite blocks are the same as for other blocks that supported it earlier. You can set the block to stop, to output some predefined values, or to output an error signal. The key feature of the composite block error handling mechanism is that it handles all errors raised by nested blocks, even if some nested block does not support error handling. However, the behavior in case of an error that appears when data is sent from one port to another with an incompatible data type does not change. In other words, block errors are handled by the composite, but errors in workflow configuration (for example, a wrong link) stop the workflow anyway.

Configuring error handling on the composite block level provides some important advantages:

• A single place to setup error handling. In a complex workflow, error handling has to be configured for all blocks which may fail execution. But if the workflow uses composite blocks, you can set up error handling on the composite block level only, without editing every nested block.
• The capability to handle errors from blocks with no error handling support. Error handling is widely supported in pSeven, but some blocks still do not provide this feature. Errors from such blocks may stop the workflow even if other blocks are configured to suppress error and continue. In this case, the best solution is to group blocks that need error handling into a composite block.

For example, the Integration Basics workflow (found in pSeven examples and tutorials) can handle invalid input values in two ways: either configure the Launcher and OutputParser blocks to output defaults on an error (as described in the tutorial) or add error handling on the composite block level to get the same outcome.

The second way requires you to change the “Error handling behavior” option value for the root composite block:

Then set a default value for the workflow output:

Error handling behavior for the Launcher and OutputParser blocks, in this case, should be the default (“stop workflow”), since errors are to be handled by the root composite block.

To test new settings, run the workflow with some invalid input. When the workflow finishes, you can see that the OutputParser block was not used: this is another advantage of the composite block error handling. The composite block stopped and output defaults as soon as the first error was encountered (the Launcher block failed due to program crash). Compare this to the initial setup where the error is handled by the Launcher and OutputParser blocks: first, it stops the Launcher that sends a default empty file to OutputParser, then OutputParser fails to parse the file, raises its own error and outputs defaults. Handling errors on the composite block level allow getting rid of error chains like this one.

As a result, the error handling support added to composite blocks provides a powerful and flexible tool to control workflow errors. It helps to reduce complexity and minimizes the risk of mistakes in workflow configuration.