RPA Error Handling in Bots

A bot without error handling is a disaster waiting to happen. Applications go down. Web pages time out. Files are missing. Data is in unexpected formats. Every real-world process has exceptions. Without proper error handling, one unexpected situation crashes the entire bot and leaves data in an inconsistent state. Robust error handling is what separates a hobby script from a production-grade automation.

Types of Errors in RPA

Application Errors

The target application behaves unexpectedly — it crashes, shows an unexpected dialog, logs out automatically, or displays a page in an unexpected state.

Selector Errors

The bot cannot find the expected UI element on screen. This happens when the application UI changes (an update moved a button), the application is in a different state than expected, or the page has not loaded fully.

Data Errors

The data in a field is empty, in the wrong format, or contains unexpected characters. For example, a currency field contains "N/A" instead of a number, causing a conversion error.

Business Rule Violations

The data fails a business rule check — for example, a duplicate invoice number, an unknown vendor, or an amount that exceeds the bot's authorised posting limit.

System / Infrastructure Errors

The bot machine loses network connectivity, a shared file is locked by another user, or the database server is unavailable.

Error Handling Architecture in UiPath

Try-Catch Block

A Try-Catch block attempts a set of activities (the Try section). If any activity throws an error, execution jumps to the Catch section, where you handle the error. The Finally section runs regardless of whether an error occurred — use it to close applications or release resources.

 TRY
 ─────────────────────────────────────────────
   Open SAP application
   Login with credentials
   Navigate to Invoice Entry screen
   Fill invoice fields
   Click Post
   Read confirmation document number
 ─────────────────────────────────────────────

 CATCH (Exception: SelectorNotFoundException)
 ─────────────────────────────────────────────
   Log: "SAP screen element not found."
   Take screenshot → save as evidence
   Send alert email to IT team
   Mark queue item as Failed
 ─────────────────────────────────────────────

 CATCH (Exception: System.Exception)
 ─────────────────────────────────────────────
   Log: "Unexpected error: " + exception.Message
   Take screenshot
   Send alert email
   Mark queue item as Failed
 ─────────────────────────────────────────────

 FINALLY
 ─────────────────────────────────────────────
   Close SAP application (regardless of error)
 ─────────────────────────────────────────────

Global Exception Handler

The Global Exception Handler in UiPath catches any unhandled error anywhere in the workflow — it is the last safety net. Define what the bot should do with an unhandled error: retry the current item, ignore it and continue, or stop the entire process.

 Global Exception Handler Configuration:
 ├── On Error Type: System.Exception
 ├── Action: RetryCurrentActivity (up to 1 time)
 ├── If retry fails: Log error and Continue to next item
 └── Always: Send error notification to admin

Retry Scope

Retry Scope automatically retries a group of activities when they fail. Use it for transient failures — like a web page that occasionally times out or a login that fails due to a slow server response.

 RETRY SCOPE
 ├── Number of Retries: 3
 ├── Retry Interval: 30 seconds
 └── Activities inside:
     [Navigate to URL]
     [Wait for page to load]
     [Find login button]

 If all 3 retries fail → error is passed to the Try-Catch above it.

Error Handling Strategy by Error Type

The Exception Queue Pattern

A well-designed bot does not stop processing when one item fails. It marks the failed item in an Exception Queue and continues with the next item. At the end of the run, the bot sends a summary of all exceptions to the business team for manual review.

 PROCESSING 200 INVOICES:
 ─────────────────────────────────────────────
 Invoice 1:  POSTED ✓
 Invoice 2:  POSTED ✓
 Invoice 3:  FAILED → added to Exception Queue
 Invoice 4:  POSTED ✓
 Invoice 5:  FAILED → added to Exception Queue
 ...
 Invoice 200: POSTED ✓
 ─────────────────────────────────────────────
 SUMMARY EMAIL:
 "195 invoices posted. 5 exceptions require review.
  Exception report attached."

Logging for Error Diagnosis

Every error handler must log enough information for a developer to diagnose the problem without needing to reproduce it. A good error log entry includes:

• The exact error message (exception.Message)
• The stack trace (exception.StackTrace) for technical errors
• The data that caused the error (invoice number, row index, vendor name)
• A screenshot of the screen at the moment of failure
• The date and time of the failure
• The workflow name and activity where the error occurred

Screenshot Activity for Evidence

 CATCH block:
 ├── Take Screenshot [Full Screen]
 │   Save to: "C:\ErrorScreenshots\" + invoiceNo + "_" + Now.ToString("yyyyMMdd_HHmmss") + ".png"
 ├── Log: "Error screenshot saved: " + screenshotPath
 └── Send alert email with screenshot attached

Summary

Error handling is the difference between a fragile proof-of-concept and a reliable production bot. Use Try-Catch blocks around risky operations, Retry Scope for transient failures, and a Global Exception Handler as the last safety net. Design bots to skip failed items and continue processing rather than stopping entirely. Log every error with enough detail to diagnose it without reproduction. Route business exceptions to a human review queue. The time invested in error handling upfront pays back many times over in reduced production failures and maintenance time.