Skip to content
Doppelganger logo

Understanding On Error Block

The On Error block is a scoped safety net for task execution. It lets you define a recovery path that runs only when an action fails later in the task. Conceptually, it behaves like a try/catch block for a segment of the action list.

What it does#

When a task runs, Doppelganger executes actions in order. If an action throws an error (missing selector, JS exception, timeout, network failure, etc.), the engine checks whether an On Error handler has been registered. If one exists, it jumps to that handler and executes its actions until the matching end.

If no error happens, the On Error block is skipped entirely.

When it activates#

  • An On Error block only activates for failures that occur after it is declared.
  • It does not catch errors from actions above it in the list.
  • If an error occurs inside the On Error handler itself, execution stops.

Why it matters#

On Error is the right tool for:

  • Fallback paths (try primary selector, then backup)
  • Clean exits (stop with a controlled error status)
  • Recovery actions (reload, wait, retry a click)
  • Capturing error context (logging or taking a screenshot)

It is not meant to mask every problem silently. It should handle known failure modes.

Example behavior#

Imagine a task tries to click a button that may or may not exist. If the click fails, the On Error block can click a backup selector, skip the rest, or stop cleanly. Without On Error, the task would fail immediately.

Best practices#

  • Keep the handler short and decisive: recover, exit, or retry.
  • Use it for known failure scenarios, not to hide unknown bugs.
  • Pair it with condition checks (if/while) to avoid unnecessary errors.
  • If you need to stop after recovery, explicitly stop.

Common mistakes#

  • Forgetting to close the On Error block with end.
  • Assuming it will catch errors from actions defined before it.
  • Putting long, slow logic in the handler, which delays recovery.
  • Expecting it to “resume” the failed action automatically.

Design patterns#

  • Fallback selector: try a primary button, then a secondary button in on_error.
  • Soft failure: take a screenshot and stop with error if a critical step fails.
  • Retry: in the handler, wait briefly and attempt a single retry action.

Summary#

The On Error block is a targeted recovery tool. Use it to keep tasks resilient and predictable when something goes wrong, but don’t rely on it as a blanket fix for every error.

Previous
Next