Try Block — Configuration
Scope mechanics, nesting rules, pairing requirements, and design guidance for the Try Block node.
No configuration required. The Try Block node has no configurable properties. It is a structural node — it declares a guarded scope boundary and pushes an exception context frame. Simply add it to your workflow before the nodes you want to protect from unhandled exceptions.
Minimal Configuration Object
The node's configuration block in the workflow definition is minimal:
{
"nodeType": "TryBlock",
"id": "try_api_call",
"label": "Try — External API Call"
}
Scope Rules
Understanding the Try Block's scope rules is essential for correct error handling behaviour:
- Any node connected after the Try Block's "success" port is considered inside the guarded scope and will have its exceptions intercepted.
- Nested try blocks are supported — place a Try Block node inside an outer try block's scope to create fine-grained error zones with different catch handlers.
- The Catch Block and Finally Block are connected at the same level as the Try Block node (siblings in the graph), not inside its scope.
- HIL nodes (Approval, Chat, Form) inside a try block will have their error ports intercepted by the catch handler. Normal suspend/resume execution is unaffected.
- A Try Block must always have a paired Catch Block in the same workflow graph. A Try Block without a Catch Block will cause a design-time validation error when you attempt to publish the workflow.
Pairing with Catch and Finally
In the workflow designer, connect nodes as follows:
- Place the Try Block node where you want guarded execution to begin.
- Connect the Try Block's "success" port to the first node that should run inside the protected scope.
- Continue building the protected scope's graph normally (all nodes reachable from the try's success port are in scope).
- Place the Catch Block node at the same level as the Try Block. The engine automatically associates the nearest Try Block with the Catch Block in execution order.
- Optionally, place a Finally Block node after the Catch Block at the same level.
Scope boundary: Only exceptions that originate within nodes directly or transitively connected from the Try Block's success port are intercepted. Exceptions from nodes that are placed before the Try Block, or on other branches of the workflow graph, are not affected by this try/catch scope.
Exception Context Frame
When the Try Block executes, it pushes an exception context frame onto the workflow's execution stack. This frame:
- Registers a handler pointer to the paired Catch Block node ID.
- Records the variable scope snapshot at the point of try entry (for potential rollback in advanced scenarios).
- Stores the EngineExecutionContext reference so the Catch Block can access full exception details.
When the scope exits normally (no exception), the frame is popped and execution continues to the Finally Block (if present) or the node immediately following the try/catch/finally trio.