Sign In

Error Handler

Catch errors from preceding nodes and route them with retry, default value, or error branch policies.

The Error Handler node intercepts failures from upstream nodes and determines what happens next. It has two output handles -- success and error -- so you can build separate paths for handled errors and unhandled failures.

Configuration

FieldTypeRequiredDescription
policyenumNoThe error handling strategy. One of errorBranch (default), continueWithDefault, or retry.
maxRetriesnumberWhen policy is retryMaximum number of retry attempts. Range is 1 to 5. Defaults to 3.
retryDelayMsnumberWhen policy is retryDelay between retries in milliseconds. Range is 100 to 30000. Defaults to 1000.
defaultValuestring (JSON)When policy is continueWithDefaultJSON value to use in place of the failed node's output. Defaults to null.

Policies

Route to error branch (errorBranch) -- The error is forwarded to the error output handle. Connect downstream nodes to this handle to build custom failure-recovery logic.

Continue with default value (continueWithDefault) -- The workflow continues through the success output handle using the configured default value as a substitute for the failed node's output.

Retry failed node (retry) -- The execution engine retries the failed node up to maxRetries times with exponential backoff starting at retryDelayMs. If all retries fail, the error routes to the error handle.

Output Handles

This node has two output handles:

  • Success (green) -- fires when the error is successfully handled (default value used, or retry succeeded).
  • Error (red) -- fires when the error is routed to the error branch, or when all retries are exhausted.

Output

FieldTypeDescription
handledbooleanAlways true -- indicates the error handler processed the failure.
errorobjectThe original error from the failed upstream node.
resultanyThe default value (for continueWithDefault) or null.
routestringWhich output handle was activated: success or error.
retryCountnumberNumber of retries configured (for retry policy) or 0.
retryDelayMsnumberDelay between retries. Only present when policy is retry.

Example

Protect an HTTP Request node that calls an unreliable third-party API. Retry up to 3 times with a 2-second delay, then fall through to an error notification.

Policy: Retry failed node
Max Retries: 3
Delay: 2000 ms

Connect the success handle to the next processing step. Connect the error handle to a notification node that alerts the team about the persistent failure.

On this page

Error Handler | Buildorado