Skip to main content
Written by RTILA Team - Senior Automation Engineer

Browsers are unpredictable. Delays, temporary outages, missing elements, and rate limits happen even on stable sites. Production-grade automation treats failures as an expected part of every run.

Try / Catch Blocks

Wrap fragile actions in a try_catch command. The engine runs the try array first. If any command in that array fails, the engine stores the error message in state.variables['last_error'] and then runs the catch array. There is no finally block.

{
  "command": "try_catch",
  "params": {
    "try": [
      {
        "command": "click",
        "params": {
          "selector": "css=#checkout-button"
        }
      }
    ],
    "catch": [
      {
        "command": "wait_for_selector",
        "params": {
          "selector": "css=#login-required"
        }
      }
    ]
  }
}

Fallback Selectors

RTILA X does not use a fallback_selectors parameter on individual commands. For extraction workflows, the recommended fallback pattern is to wrap two extract_data commands in a try_catch block. The try block attempts the primary dataset first; if it fails, the engine records the error in state.variables['last_error'] and runs the catch block, which tries an alternate dataset or logs the issue.

{
  "command": "try_catch",
  "params": {
    "try": [
      {
        "command": "extract_data",
        "params": {
          "dataset": "product_cards_primary",
          "output_filename": "products.json"
        }
      }
    ],
    "catch": [
      {
        "command": "extract_data",
        "params": {
          "dataset": "product_cards_fallback",
          "output_filename": "products.json"
        }
      }
    ]
  }
}

Retry Patterns

For transient failures, wrap the action in a repeat or while loop with a short pause between attempts. Retry is especially useful for loading spinners, WebSocket updates, and API-driven widgets.

HTTP Error Handling

Commands such as http_request return status codes and response data. Use an if command to branch on failed HTTP status codes before trying an alternate endpoint or logging the error.

{
  "command": "http_request",
  "params": {
    "url": "https://learn.rtila.com/api/status.json",
    "method": "GET"
  }
}

Batch Error Recovery

When processing a list of product URLs, a single 404 on one detail page should not stop the other pages. Use try_catch inside a for_each block and collect failed URLs into a separate variable for later review.

Retry Count and Timeouts

Keep retry attempts finite. A three-attempt pattern with increasing delays is usually enough:

  1. First attempt: wait 2 seconds
  2. Second attempt: wait 5 seconds
  3. Final attempt: wait 10 seconds or skip the item

Try It Yourself

Run each of the five Error Handling scenarios in order. They demonstrate missing selectors, fallback recovery, HTTP failures, loop-level recovery, and batch retry behavior.

Was this helpful?

โ† Back to Learning Hub