Try Catch
A programming mechanism that catches errors locally within a flow, supporting in-place degradation, fallback or retry, with node-level control granularity.
Timeline (last 90 days)
n8n's Try Catch inline handling isolates risky nodes locally within the flow, capturing errors in place and attempting degradation or fallback when they occur, with node-level control granularity.
The Error Trigger's trigger condition is "the entire execution failed", not a single node reporting an error; if a node error is caught and handled by Try Catch, the execution does not terminate in an error state, and the Error Trigger will not fire.
A safer approach is to use both layers: an outer Error Trigger Node to catch all errors not handled locally and push notifications, and an inner Try Catch on known high-risk nodes for in-place retry or degradation handling.
If every node is wrapped in Try Catch, the flow becomes bloated and hard to maintain; if only a global trigger is used, the opportunity for graceful recovery within the flow is lost.
In n8n's Try Catch node, rethrowing an error (rethrow) can usually be achieved by configuring the "Throw Error" option or manually throwing an error in the Catch branch.
Whether to rethrow an error depends on business semantics: degradable errors (such as cache misses or missing non-critical fields) can be absorbed in place; non-degradable errors (such as authentication failures or loss of core data) should be rethrown to avoid being silently swallowed.
The criterion for choosing between Try Catch and Error Trigger can be simplified to: when this error occurs, can the flow still meaningfully continue? If yes, use Try Catch inline handling; if not, let it fail and hand over to the Error Trigger for alerting and follow-up actions.
Error Trigger and Try Catch are not substitutes but complementary: the global safety net ensures nothing goes unreported, and inline handling ensures recoverability.
All Facts (8)
n8n's Try Catch inline handling isolates risky nodes locally within the flow, capturing errors in place and attempting degradation or fallback when they occur, with node-level control granularity.
50%UnverifiedThe Error Trigger's trigger condition is "the entire execution failed", not a single node reporting an error; if a node error is caught and handled by Try Catch, the execution does not terminate in an error state, and the Error Trigger will not fire.
50%UnverifiedA safer approach is to use both layers: an outer Error Trigger Node to catch all errors not handled locally and push notifications, and an inner Try Catch on known high-risk nodes for in-place retry or degradation handling.
50%UnverifiedIf every node is wrapped in Try Catch, the flow becomes bloated and hard to maintain; if only a global trigger is used, the opportunity for graceful recovery within the flow is lost.
50%UnverifiedIn n8n's Try Catch node, rethrowing an error (rethrow) can usually be achieved by configuring the "Throw Error" option or manually throwing an error in the Catch branch.
50%UnverifiedWhether to rethrow an error depends on business semantics: degradable errors (such as cache misses or missing non-critical fields) can be absorbed in place; non-degradable errors (such as authentication failures or loss of core data) should be rethrown to avoid being silently swallowed.
50%UnverifiedThe criterion for choosing between Try Catch and Error Trigger can be simplified to: when this error occurs, can the flow still meaningfully continue? If yes, use Try Catch inline handling; if not, let it fail and hand over to the Error Trigger for alerting and follow-up actions.
50%UnverifiedError Trigger and Try Catch are not substitutes but complementary: the global safety net ensures nothing goes unreported, and inline handling ensures recoverability.
50%