Trading Networks 10.3 | Administering and Monitoring B2B Transactions | Service Development Help | Failure Handling in Flow Services Using the TRY, CATCH, and FINALLY Steps | Summary of TRY, CATCH, and FINALLY Behavior
 
Summary of TRY, CATCH, and FINALLY Behavior
Below is a summary of the runtime behavior for the TRY, CATCH, and FINALLY steps.
*A TRY step can be followed by one or more CATCH steps and/or a FINALLY step.
*A TRY step can stand alone with no associated CATCH or FINALLY steps.
Designer provides a visual, semantic warning when a TRY step is not followed by a CATCH or FINALLY step. However, Integration Server still executes the TRY step at run time. In contrast, it is not valid for a CATCH or FINALLY step to exist without a preceding TRY step. At run time, Integration Server does not execute a CATCH or FINALLY step that is not preceded by a TRY step.
*If a TRY step fails and it is not followed by a CATCH step or a FINALLY step, Integration Server propagates the pending failure up to the parent flow step.
*If a CATCH step is not immediately preceded by a sibling TRY step, Integration Server ignores the CATCH step and does not execute it.
*If a FINALLY step is not preceded by a sibling TRY step (and possibly intervening CATCH steps), Integration Server ignores the FINALLY step and does not execute it.
*Disabling a TRY step causes any associated sibling CATCH and/or FINALLY steps to be ignored.
*If TRY step completes successfully, Integration Server ignores any CATCH steps that immediately follow it. Integration Server then executes any associated FINALLY step.
*If a step within the TRY step fails and the TRY step is immediately followed by a matching CATCH step, Integration Server reacts to the failure by skipping the remainder of the steps in the TRY step. Integration Server then executes the matching CATCH step.
*When there are multiple CATCH steps associated with a TRY step that fails, Integration Server executes the first matching CATCH step and ignores any subsequent CATCH steps associated with the TRY step. Consequently the order in which CATCH steps appear after a TRY step is important.
*If no CATCH step handles the failure from the TRY step, then Integration Server executes the associated FINALLY step, if one exists. Integration Server then propagates the failure from the TRY step to the parent flow step.
*After the TRY and possibly the CATCH step completes, Integration Server executes any following FINALLY step. Integration Server always executes the FINALLY regardless of whether the TRY step succeeds or fails and whether a matching CATCH step exists. The exception to this is when any step contains an EXIT step configured to exit $flow and signal failure.
*If the Failures property of a CATCH step is left empty, the CATCH step will handle the last failure thrown regardless of what it is. However, a CATCH step cannot handle a failure created by an EXIT step configured to signal failure and exit from $flow when the EXIT step is in the same flow service.
*If a new failure occurs within a CATCH step, it results in a new, pending failure. Integration Server discards the original failure. After executing any associated FINALLY step, Integration Server propagates the new pending failure to the parent flow step.
*When a FlowException occurs in a flow service because of a flow definition error or because Integration Server executes an EXIT step configured to exit from the $flow and signal failure, Integration Server terminates the entire flow service immediately. Integration Server does not execute any remaining CATCH or FINALLY steps in the terminated flow service.
Note:
For information about TRY, CATCH, and FINALLY step behavior with normal completion, abrupt completion, or failure, see Normal and Abrupt Completion and Failure of TRY, CATCH, and FINALLY Steps.