Skip to main content
Figranium provides several mechanisms to make your automation tasks resilient to failures — from optional actions to retry loops and fallback sub-tasks.

​
Why Tasks Fail

Common failure modes in browser automation:
  • An element takes longer than expected to appear (timeout)
  • A popup or modal interrupts the expected flow
  • A network request fails or times out
  • A selector becomes stale after a navigation
  • A CAPTCHA is triggered
  • Dynamic content changes the page structure
A well-designed task anticipates these failures and handles them gracefully.

​
The On Error Block

The On Error block is Figranium’s primary error handling mechanism. It works like a try/catch: if any action in the main flow raises an error, execution jumps to the on_error block.
The on_error / end pair should be placed in the task to catch errors from preceding actions. Any error thrown by an action before the on_error block is caught.

​
Making an Action Optional

The simplest use: place an empty on_error/end block to absorb errors from an action that may or may not exist:

​
Fallback Action

Perform a fallback action when the primary approach fails:

​
Stop on Error with a Reason

Log the failure and stop the task cleanly:

​
Retry Patterns

​
Retry with a Counter Variable

Use a while loop combined with a counter to retry a failing action up to N times:
This retries up to 3 times with a 2-second pause between attempts, then continues if any attempt succeeds.

​
Retry a Login

​
Handling Popups and Modals

Popups that appear unpredictably are a common cause of task failures. Handle them proactively.

​
Check and Dismiss Before Proceeding

​
Dismiss Any Popup on Every Page

Use a sub-task triggered via start to handle common popups at the beginning of every task:

​
Timeout Strategies

Each action block can have its own timeout (in milliseconds). Use shorter timeouts for elements that should appear quickly, and longer ones for slow-loading content.
Use on_error around short-timeout actions to make them non-fatal when the element doesn’t appear.

​
Logging Errors for Inspection

Use a javascript block inside on_error to log diagnostic information to the execution output:
The returned object appears in the execution detail view, giving you context about what the page looked like when the failure occurred.

​
Output Provider Error Handling

When using Output Providers, you can control what happens if the data push to an external service fails:
  • onError: "ignore" (default): The execution is marked as successful even if the push fails.
  • onError: "fail": The execution is marked as failed if the push fails.
Choose fail when data delivery is critical and you want alerts on push failures.