Catching exceptions in a TryCatch node

You can design a message flow to catch exceptions before they are returned to the input node. You can include one or more TryCatch nodes in a flow to provide a single point of failure for a sequence of nodes. With this technique, you can provide specific error processing and recovery.

About this task

A TryCatch node does not process a message in any way, it represents only a decision point in a message flow. When the TryCatch node receives a message, it propagates it to the Try terminal. The integration node passes control to the sequence of nodes that are connected to that terminal (the try flow).

If an exception is thrown in the try flow, the integration node returns control to the TryCatch node. The TryCatch node writes the current contents of the exception list tree to the local error log, then writes the information for the current exception to the exception list tree, overwriting the information that is stored there.

The TryCatch node propagates the message to the sequence of nodes that are connected to the Catch terminal (the catch flow). The content of the message tree that is propagated is identical to the content that was propagated to the Try terminal, which is the content of the tree when the TryCatch node first received it. The node enhances the message tree with the new exception information that it has written to the exception list tree. Any modifications or additions that the nodes in the try flow made to the message tree are not present in the message tree that is propagated to the catch flow.

However, if the try flow completes processing that involves updates to external databases, these updates are not lost; they persist while the message is processed by the catch flow, and the decision about whether the updates are committed or rolled back is made on the configuration of your message flow and the individual message flow nodes that interact with the databases. If the updates are committed because of the configuration that you set, you must include logic in your catch flow that rolls back the changes that were made.

To review the options for configuration, see Configuring transactionality for message flows.

If an exception is thrown in the catch flow of the TryCatch node (for example, if you include a Throw node, or code an ESQL THROW statement, or if the integration node generates the exception), then the integration node returns control to the next catch point in the message flow, such as another TryCatch node.

The following example shows how you can configure the flow to catch exceptions in the input node. The MQInput node's Catch terminal is connected to a Trace node to record the error.

This message flow has an MQInput node, a Compute node and an MQOutput node. The catch terminal of the MQInput node is connected to a Trace node.

In the following example, the message flow has two separate processing flows connected to the Filter node's True and False terminals. Here a TryCatch node is included on each of the two routes that the message can take. The Catch terminal of both TryCatch nodes is connected to a common error processing subflow.

This message flow has an MQInput node followed by a Filter node, which is coded to test a value in the message. A TryCatch node is connected to the Filter node's true terminal, and its try terminal is connected to a Compute node followed by an MQOutput terminal. Its catch terminal is connected to a subflow called error1, which provides a common error processing routine. A second TryCatch terminal is connected to the Filter node's false terminal. It's try and catch terminals are connected to sequences of nodes identical to the first TryCatch terminal.

If the input node in your message flow does not have a Catch terminal, and you want to process errors in the flow, you must include a TryCatch node.