Handle errors in patterns

Automations interact with the outside world — APIs go down, data arrives in unexpected formats, and services time out. Without error handling, a single failure stops the entire pattern. DRAGOPS provides four error handling nodes for building resilient patterns that recover from failures gracefully.

Why error handling matters

Consider a pattern that fetches data from an external API, transforms it, and posts the result to a webhook. Any of these steps can fail:

• The API returns a 500 error or times out
• The response body is missing an expected field
• The destination webhook rejects the request

Without error handling, the pattern stops at the point of failure and reports an error in the execution log. With error handling, you can retry transient failures, fall back to alternative logic, and log diagnostic information.

Try / Catch

The Try / Catch node wraps a section of your pattern in structured error handling. It has three execution output pins and one data output pin:

• Try — The main logic runs here. Wire the nodes you want to protect to this pin.
• Catch — Runs if any node in the Try branch raises an error.
• Finally — Runs after Try or Catch completes, regardless of whether an error occurred.
• Error (data pin, Object type) — Available in the Catch branch. Contains message and type fields describing what went wrong.

How to use Try / Catch

1. Right-click on the canvas and search for "Try / Catch". Add the node to the canvas.
2. Wire the execution flow into Try / Catch's input execution pin.
3. From the Try output pin, wire the nodes that might fail (for example, an HTTP Request node).
4. From the Catch output pin, wire your fallback logic (for example, a Log node that records the error).
5. Optionally, wire cleanup logic to the Finally pin.

To access the error details in the Catch branch, drag from the Error data pin to a Get Property node and extract the message or type field.

Example: Protect an HTTP request

If HTTP Request succeeds, the Try branch runs to completion and the Finally branch runs. If HTTP Request fails, execution jumps to the Catch branch, logs the error, and then the Finally branch runs.

Retry

The Retry node automatically retries a block of logic when it fails. This is ideal for transient failures such as network timeouts or rate-limited API responses.

Input pins

Output pins

How to use Retry

1. Right-click on the canvas and search for "Retry". Add the node to the canvas.
2. Wire the execution flow into Retry's input execution pin.
3. From the Body output pin, wire the operation you want to retry (for example, an HTTP Request node).
4. From the Success output pin, wire the logic that should run after the operation succeeds.
5. From the Failure output pin, wire fallback logic for when all attempts are exhausted.

With the default settings (3 attempts, 1 second delay, 2x backoff multiplier), the retry schedule is:

• Attempt 1: immediate
• Attempt 2: after 1 second
• Attempt 3: after 2 seconds

Example: Retry an API call

On Error

The On Error node is a global error handler. It triggers when an unhandled error occurs anywhere in the pattern — any error that is not caught by a Try / Catch node.

Output pins

How to use On Error

1. Right-click on the canvas and search for "On Error". Add the node to your canvas.
2. From its execution output pin, wire the logic you want to run when an unhandled error occurs (for example, send an alert or log the error).
3. Use the Error data pin to access error details.

On Error acts as a safety net. It does not prevent the pattern from failing — the execution still reports as failed. But it gives you a chance to run cleanup logic, send notifications, or log diagnostic information before the execution ends.

You do not need to wire On Error into the main execution flow. Place it anywhere on the canvas — it activates automatically when an unhandled error occurs.

Example: Log unhandled errors

Throw Error

The Throw Error node intentionally raises an error with a custom message. Use it to enforce preconditions, signal invalid states, or test your error handling.

Input pins

How to use Throw Error

1. Right-click on the canvas and search for "Throw Error". Add the node to the canvas.
2. Wire the execution flow into Throw Error's input execution pin.
3. Set the Message pin to describe the error (for example, "Missing required field: email").

When Throw Error executes, it raises an error that propagates up the execution flow. If a Try / Catch node wraps the Throw Error, the Catch branch handles it. Otherwise, the On Error handler catches it. If neither exists, the pattern fails with the error message in the execution log.

Example: Validate input data

Combining error handling nodes

The four error handling nodes work together to create layered resilience. Use them in combination for production-grade patterns.

Recommended approach

1. Retry for transient failures — Wrap API calls and external requests in a Retry node to handle temporary outages.
2. Try / Catch for expected errors — Wrap sections of logic that might fail in known ways, and provide specific fallback behavior in the Catch branch.
3. Throw Error for validation — Check preconditions early and raise descriptive errors when the input data is invalid.
4. On Error as a safety net — Add a global error handler to catch anything unexpected, log it, and optionally send an alert.

Example: HTTP request with retry and fallback logging

This pattern calls an external API with retry logic, catches failures, and uses On Error as a final safety net. Drag the nodes around or disconnect and reconnect wires to explore:

In this setup:

1. The HTTP Request node retries up to three times with exponential backoff.
2. If all retries fail, Throw Error raises an error that Try / Catch catches.
3. The Catch branch logs the error message.
4. The Finally branch runs regardless of outcome.
5. If any other unexpected error occurs outside the Try / Catch, the On Error handler logs it.

What is next?