Exceptions
Nodes throw. A file is not where it was, a site changed, a credential expired. What happens next depends on whether you planned for it.
Run from the Designer, the robot pauses at the failing node so you can see it. Run unattended — a schedule, a trigger, a production robot — an unhandled exception stops the flow immediately.
Catch
Catch is a trigger, not a step: nothing wires into it. When a node it is watching throws, the flow resumes from the Catch node with the error attached to the message.
Here is the Handle Errors template, which is built entirely around this idea:
Read the lower half. Catch Errors receives the failure, a Switch asks what is the error
type?, and each type gets its own response — one shows a message and gives up, the other
loops back to Retry to ask again. That is the shape of real error handling: not one handler,
but a decision about which failure this is.
Choosing what to catch
A Catch node catches selectively — you pick the nodes it watches in its properties. That matters, because a Catch that swallows everything makes every failure look the same.
Selecting nodes one at a time gets old fast. Group them into a Sub Flow and the Catch node selects one thing.
The message arriving at the Catch node carries an error field, which is what the Switch above is branching on.
Continue On Error
Sometimes a failure genuinely does not matter. Every node has a Continue On Error switch in the Common section of its properties: turn it on and the node will not throw — the flow carries on.
Use it sparingly. It hides the cause of a problem, which is why the robot still records a warning in the log when a node fails with Continue On Error set. If a flow is producing strange results and nothing has errored, that log is the first place to look.
| Approach | Use when |
|---|---|
| Catch | The failure needs a response — retry, notify, take another path |
| Continue On Error | The failure genuinely does not matter and the flow should carry on |
| Neither | The flow should stop. This is the right default more often than people think |
See also
- Debugging — for wrong values rather than errors
- Handling Failure — the tutorial, built on this template
- Jobs — where an unattended failure is recorded