Catch Block — Input & Output
Output port, exception memory variables, access patterns, and catch scope execution mechanics.
Output Ports
| Port | Fires When | Notes |
|---|---|---|
| success | An exception was caught from the paired Try Block scope and the Catch Block is now executing. | All three exception memory variables are populated and available to all downstream nodes in the catch scope. |
The Catch Block only executes when an exception actually occurred. If the Try Block scope completed without an exception, the Catch Block is skipped entirely. You cannot force the Catch Block to execute programmatically — it is exclusively driven by the exception mechanism.
Memory Variables Available in Catch Scope
| Variable (default prefix) | Type | Description |
|---|---|---|
$mem.__exception_type__ |
string | The fully-qualified .NET exception class name. Use in Switch node conditions to branch on different exception types. |
$mem.__exception_message__ |
string | The exception's Message property. Human-readable. Safe to include in user-facing notifications (contains no stack trace). |
$mem.__exception_stacktrace__ |
string | The full stack trace string. For internal logs and debugging only — do not expose to end users. |
Accessing Variables in Catch Nodes
// In a Slack notification node message property
"Workflow error in {{ $var.workflow_name }}:
Type: {{ $mem.__exception_type__ }}
Message: {{ $mem.__exception_message__ }}
Record ID: {{ $var.current_record_id }}"
// In a Set Variable node to persist error info
$var.last_error_type = $mem.__exception_type__
$var.last_error_message = $mem.__exception_message__
// In a Switch node condition to branch on exception type
$mem.__exception_type__ === "HttpRequestException"
$mem.__exception_type__ === "TimeoutException"
// In a Database Insert node to log the error
{
"workflow_id": "{{ $ctx.workflow_instance_id }}",
"error_type": "{{ $mem.__exception_type__ }}",
"error_message": "{{ $mem.__exception_message__ }}",
"occurred_at": "{{ $now }}",
"context": "{{ $var.current_record_id }}"
}What Data Remains Available in the Catch Scope
Inside the catch scope, all workflow variables that were set before and during the Try Block scope are still accessible. This means:
- Variables set by nodes that ran successfully before the exception node are available.
- Variables set by the exception-throwing node itself may be partially set or absent — treat them as potentially undefined.
- Variables set before the Try Block node (in the broader workflow) are fully available.
- The workflow instance ID, run ID, and execution context are always available via
$ctx.