Message tree contents after an exception

The contents of the message tree are updated if an exception is raised.

If no exception occurs while processing the message, the tree structure and content received by an individual message flow node is determined by the action of previous nodes in the flow. If an exception occurs in the message flow, the content of the four trees depends on the following factors:

  • If the exception is returned to the input node, and the input node Catch terminal is not connected, the trees are discarded. If the message is in a transaction, it is returned to the input queue for further processing. When the message is processed again, a new tree structure is created. If the message is not in a transaction, it is discarded.
  • If the exception is returned to the input node and the Catch terminal is connected, the message and local environment trees that were created originally by the input node, and propagated through the Out terminal, are restored, and any updates that you made to their content in the nodes that followed the input node are lost. The environment tree is not restored, and its contents are preserved. If the nodes following the input node include a Compute node that creates a new local environment or message tree, those trees are lost. The exception list tree reflects the one or more exceptions that have been recorded.
  • If the exception is caught in the message flow by a TryCatch node, the message and local environment trees that were previously propagated through the Try terminal of the TryCatch node are restored and propagated through the Catch terminal. Any updates that you made to their content in the nodes that followed the TryCatch node are lost. The environment tree is not restored, and its contents are preserved. If the nodes following the TryCatch node include a Compute node that creates a new local environment or message tree, those trees are lost. The exception list tree reflects the one or more exceptions that have been recorded.

Exception handling paths in a message flow

Exception handling paths start at a failure terminal (most message processing nodes have these), the Catch terminal of an input node, a TryCatch node, or an AggregateReply node, but are no different in principle from a normal message flow path. Such a flow consists of a sequence of nodes connected together by the designer of the message flow. The exception handling paths differ in the kind of processing that they do to record or react to the exception. For example, they might examine the exception list to determine the nature of the error, and take appropriate action or log data from the message or exception.

The local environment and message tree that are propagated to the exception handling message flow path are those at the start of the exception path, not those at the point when the exception is thrown. The following figure illustrates this point:

Diagram shows an extract of a message flow, which is described in the following text
  • A message (M1) and local environment (L1) are being processed by a message flow. They are passed through the TryCatch node to Compute1.
  • Compute1 updates the message and local environment and propagates a new message (M2) and local environment (L2) to the next node, Compute2.
  • An exception is thrown in Compute2. If the failure terminal of Compute2 is not connected (point B), the exception is propagated back to the TryCatch node, but the message and local environment are not. The exception handling path starting at point A has access to the first message and local environment, M1 and L1. The environment tree is also available and retains the content it had when the exception occurred.
  • If the failure terminal of Compute2 is connected (point B), the message and local environment M2 and L2 are propagated to the node connected to that failure terminal. The environment tree is also available and retains the content it had when the exception occurred.