Catch

Catch errors thrown by nodes on the same tab.

Use a Catch node to create an explicit error-handling branch in your flow. When a node throws an error at runtime, the Catch node receives a normal message that you can inspect, log, transform, and route onward.

Output

Catch outputs the original message with error details attached under msg.error.

• msg.error.message - the error message

• msg.error.source.id - the id of the node that threw the error

• msg.error.source.type - the type of the node that threw the error

• msg.error.source.name - the node name, if one was set

If the incoming message already has an error property, it is copied to msg._error before the new error details are attached.

In some advanced cases, Contextual nodes also preserve the underlying runtime error on msg._contextual.error. This is most useful with Contextual http-* nodes, where the raw error can include fields such as status, statusText, contentType, body, and retryCount.

Treat msg._contextual.error as a node-specific detail. msg.error is the stable Catch contract to build around.

Scope

By default, Catch handles errors thrown by any node on the same tab. You can also target it at specific nodes when you want only one branch of the flow to handle failures from that source.

Catch scopes by source node, not by matching a particular error message or error type.

If you enable uncaught-only handling, this Catch node runs only when no other matching Catch node has already handled the error.

When an error is thrown, all matching Catch nodes receive the message.

If an error is thrown inside a subflow, Catch nodes inside that subflow get the first chance to handle it. If none exist there, the error propagates up to the tab that contains the subflow instance.

On the parent tab, a Catch node scoped to that subflow instance can handle the propagated error.

For example, you might target a Catch node at an HTTP Request or Function node so only failures from that branch enter a retry or recovery path.

Common patterns

• route unexpected event-flow failures to Event Error

• transform HTTP-flow errors into a status code and response body before HTTP Response

• send the error message to Log Tap, Debug, or another notification path

Practical guidance

Keep the catch branch simple and intentional. The most useful pattern is usually one clear error path per tab, rather than many disconnected error-handling branches.