The Try scope allows you to handle errors that may occur when attempting to execute any of the components inside the Try scope. It also supports transactions. A Try scope wraps one or more event processors, then catches and handles any exceptions that might be thrown by any of these enclosed event processors. The behavior is as if you extracted those enclosed event components into a separate flow with its own error handling strategy, but inline, without having to actually define a new flow.
The Try scope has its own error handling strategy that you configure in the same way you configure error handling for a flow. It supports error handling on its inner components instead of the entire flow so that you do not have to extract them into a separate flow.
Like all error handling, the Try scope can also distinguish between various error type conditions and apply different behaviors to each error type condition.
Just like any error that is raised inside a flow, if an error is raised by a component inside a Try scope, then the Try scope’s error handler is executed, and the error is routed to the matching handler. At this point, the error is available for inspection, so the handlers can execute and act accordingly:
An On Error Continue will execute and use the result of the execution as the result of its owner, as if the owner actually completed the execution successfully. Any transactions at this point are also committed.
An On Error Propagate will roll back any transactions, execute, and use that result to rethrow the existing error, meaning that its owner will be considered as failing.
If the Try scope has several components, then once a component raises an exception, subsequent components in the Try scope are skipped, regardless of the type of error handler that catches the exception. In the case of On Error Propagate, the error is propagated to the flow’s error handling, as if the Try scope did not exist. In the case of On Error Continue, processing continues outside the Try scope at the next downstream flow component, as if the Try scope never threw an exception.
In the example above, any database connection errors (DB:CONNECTIVITY) are propagated because of the On Error Propagate (
on-error-propagate) setting. Propagation of this error causes the Try process to fail and the flow’s error handler to execute. Other errors are handled through On Error Continue (
on-error-continue), so the Try is treated as successful when they occur, meaning that the next processor, an HTTP request, continues to execute.
Within your flow, you can group a set of event processors that may throw an error inside a Try Scope. The Try Scope allows you enclose various event processors in your flow and assign it an Error Handler scope in case that operation may fail.
You can also configure the operation inside the Try Scope to be processed as a transaction.
You configure a Try scope so that it treats its child operations as an indivisible transaction. A transaction is a series of actions that should never be partially executed. Every operation within the scope of a transaction is executed in the same thread, and errors should lead to either a rollback or a commit.
The Try scope treats child operations as a transaction when the Transactional Action (
transactionalAction) is set to
BEGIN_OR_JOIN. It can be configured in the following ways:
Default. Actions are not treated as a transaction. Errors cause no rollbacks or commits.
Always Begin (
A new transaction is started every time the scope is executed.
Begin or Join (
Only relevant in cases where execution order may vary (for example, due to asynchronous actions occurring outside the flow): If the current processing of the flow has already begun a transaction, join it. Otherwise, begin a new one.