Study guide
10.2 Global Exception Handler Architecture & ErrorAction Directives
UiPath Automation Developer Professional UiPath-ADPv1
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Blueprint Map
1.1 About the UiPath-ADPv1 Exam: Format, Fees & Policies 1.2 The Exam Topics Mapped to This Guide & a Study Plan
2 Chapter 2: REFramework Architecture & State Dynamics
2.1 State Machine Architecture & The Four Core States 2.2 Configuration Management: Settings, Constants, and Assets 2.3 Transaction Types & The Dispatcher vs. Performer Architecture 2.4 Adapting REFramework: Tabular Data, Collections & Linear Processes
3 Chapter 3: REFramework Exception Handling & Recovery
3.1 BusinessRuleException vs. System.Exception Handling Patterns 3.2 Retry Mechanisms: Queue Retries vs. REFramework MaxRetryNumber 3.3 Consecutive System Exceptions & Graceful Process Termination
4 Chapter 4: State Machines, Custom Log Fields & REFramework Testing
4.1 Building State Machine Projects in Studio 4.2 Logging Levels, Robot Logs & Custom Log Fields in REFramework 4.3 Testing a REFramework Project With and Without Orchestrator Queues
5 Chapter 5: LINQ Queries & DataTable Operations
5.1 LINQ Essentials for Collections & Filtering 5.2 Advanced DataTable Querying with LINQ 5.3 In-Memory DataTable Transformations & Column Operations
6 Chapter 6: Regex, DateTime, JSON & Invoke Activities
6.1 Regular Expressions & Text Parsing for Automation 6.2 DateTime Formatting, Timezone Conversions & TimeSpan Calculations 6.3 JSON Parsing, JSONPath & Serialization with Newtonsoft.Json 6.4 Invoke Method & Invoke Code Activities 6.5 Data Referencing in Invokes: DataTable, List & Dictionary Arguments
7 Chapter 7: Modern UI Automation & Unified Targeting
7.1 Modern Design Experience & The Unified Target Concept 7.2 Anchors, Relative Elements & UI Automation Activities 7.3 Dynamic Selectors, Variables & Wildcards in Selectors
8 Chapter 8: Object Repository, Computer Vision & Remote Runtime
8.1 Object Repository & UI Descriptor Libraries 8.2 AI Computer Vision for Unattended & Remote Interfaces 8.3 Automation in Virtual Environments & UiPath Remote Runtime
9 Chapter 9: Advanced UI Automation: Browser Modes, Agentic UI & macOS
9.1 Browser Automation with the WebDriver Protocol 9.2 Agentic UI Automation: ScreenPlay, Semantic Activities & Healing Agent 9.3 macOS Automation: Native Apps, Office Apps & AppleScript
10 Chapter 10: Advanced Control Flow & Exception Architecture
10.1 Flowcharts, Sequences & Parallel Control Flow Patterns 10.2 Global Exception Handler Architecture & ErrorAction Directives 10.3 TryCatch, Retry Scope & Custom Exception Architectures
11 Chapter 11: Orchestrator Queues & Transaction Management
11.1 Queue Architecture, SpecificContent & Transaction Lifecycles 11.2 Queue Items SLA, Postpone, Deadlines & Priority Scheduling 11.3 Bulk Operations, Transaction Status Updates & Queue Triggers
12 Chapter 12: Orchestrator Tenant & Folder Entities
12.1 Asset Types, Per-Robot Assets & External Credential Stores 12.2 Modern Folder Hierarchy, User/Robot Assignment & Permissions 12.3 Storage Buckets, Webhooks & Environment Promotion 12.4 Orchestrator Tags: Labels, Properties & Governance
13 Chapter 13: Unattended Execution, API Triggers & Cloud Robots
13.1 Unattended Job Execution: Folders, Priorities, Background vs. Foreground & Runtimes 13.2 API Triggers: Starting Jobs from External Systems over HTTP 13.3 Serverless and Cloud VM Robots: Cloud-Hosted Execution Options
14 Chapter 14: Monitoring, Recording & Solutions Management
14.1 Orchestrator Monitoring, Trigger Alerts & Job Health 14.2 Job and Transaction Recording: Troubleshooting Faulted Unattended Jobs 14.3 Solutions Management: Packaging and Deploying Automations with Their Resources
15 Chapter 15: Debugging, Remote Debugging & Profiling
15.1 Studio Debugging Tools: Breakpoints, Panels & Execution Control 15.2 Remote Debugging: Remote Machine and Unattended Robot Connections 15.3 Profile Execution: Finding Performance Bottlenecks in Studio
16 Chapter 16: RPA Testing & Test Suite
16.1 UiPath Test Suite Overview, Test Cases & Given-When-Then Structure 16.2 Data-Driven Testing, Test Verification Activities & Mock Activities 16.3 CI/CD Pipelines with uipcli & Test Manager Traceability
17 Chapter 17: Long-Running Workflows, Action Center & Apps
17.1 Long-Running Workflows: Persistence, Suspend and Resume 17.2 Action Center & Human-in-the-Loop Orchestration 17.3 UiPath Apps: Action Apps, Automations & Integration Service
18 Chapter 18: Trigger-Based Attended Automation & Callouts
18.1 Trigger-Based Attended Automation: Forms, Triggers & Global Variables 18.2 Running Local Triggers & the Event Inspection Tool 18.3 Callouts & Forms for Attended Guidance
19 Chapter 19: UiPath Assistant & Robot Sessions
19.1 UiPath Assistant: Automations, Reminders, Widgets & Configuration 19.2 Robot Session (Picture in Picture): Child Session vs. Virtual Desktop
20 Chapter 20: Autopilot for Developers & Autopilot for Everyone
20.1 Autopilot for Developers: AI Assistance in Studio and Studio Web 20.2 Autopilot for Everyone: Chat, Automations & Clipboard AI
21 Chapter 21: API Automation & Integration Service
21.1 Integration Service: Connectors, Connections & Connector Activities 21.2 API Workflows in Studio Web 21.3 HTTP Requests: Web APIs, the Orchestrator API & Connector Requests 21.4 Connector Builder: Custom Integration Service Connectors 21.5 Integration Service Event Triggers: Connected and Disconnected 21.6 GenAI Activities: Generative AI Inside Workflows
22 Chapter 22: Data Service, Context Grounding & Coded Workflows
22.1 Data Fabric (Data Service) Entities: Modeling Business Data 22.2 Data Fabric Activities and the Platform Connector 22.3 Context Grounding: Retrieval-Augmented Generation with Company Data 22.4 Coded Automations: Structure, Arguments & Invoking Workflows 22.5 Coded Automation Services: Orchestrator, UI Automation, Microsoft 365 & Custom Services
23 Chapter 23: Integrated Scenario Practice
23.1 Integrated Scenario Practice: Designing an End-to-End Solution
10.2 Global Exception Handler Architecture & ErrorAction Directives
Key Takeaways Explain This Topic AI
A project can have one Global Exception Handler, it is not available in library projects, and any workflow except Main.xaml can be set as the handler.
The handler has two arguments: errorInfo (In) with the Exception, ActivityInfo, and RetryCount, and result (Out) with the ErrorAction to take.
ErrorAction values: Continue rethrows the exception, Ignore continues from the next activity, Retry re-runs the failed activity, and Abort stops after the handler runs.
The handler runs for each activity in the call stack, but not for activities placed directly in a Try block; group them in a Sequence inside the Try.
Guard Retry with errorInfo.RetryCount to avoid endless loops, and keep transaction-level recovery in REFramework.
Last updated: September 2026
10.2 Global Exception Handler Architecture & ErrorAction Directives
Core Concept: The Global Exception Handler (GEH) is an enterprise project-level architectural safety net in UiPath Studio. Configured as a specialized .xaml workflow, the Global Exception Handler runs when an activity throws an execution error and decides what happens next. By inspecting rich execution telemetry via the errorInfo input argument, the handler dynamically directs the workflow runtime using ErrorAction directives—enabling in-place activity retries, controlled process aborts, silent error suppression, or upward exception rethrowing.
In enterprise automation environments, robust error handling is the primary determinant of production reliability. While local TryCatch containers allow developers to manage expected, anticipated errors at specific transaction boundaries, unexpected application glitches—such as transient network timeouts, third-party desktop rendering delays, or intermittent background OS resource locks—can occur anywhere within a process. The Global Exception Handler provides a centralized, deterministic framework to manage these unhandled exceptions without requiring developers to wrap every single activity in defensive boilerplate code.
1. Global Exception Handler Architecture & Invocation Lifecycle
The Global Exception Handler operates at the compilation root of a UiPath Studio project. It is created using the specialized Global Handler workflow template (typically named GlobalHandler.xaml ). What happens when an activity throws an error (Global Exception Handler set)
- [Activity throws an exception]
- │
- ▼
- [Global Exception Handler runs for that activity]
- (not for activities placed directly in a Try block;
- group them in a Sequence inside the Try)
- │
- ▼
- [Inspect errorInfo, assign an ErrorAction to result]
- │
- ┌─────────┼──────────┬──────────────┐
- ▼ ▼ ▼ ▼
- Retry Ignore Continue Abort
- (re-run (go to (rethrow: an (stop after the
- activity) next enclosing Catch handler finishes)
- activity) can handle it)
- Key Architectural Constraints
Singleton Per Project: An automation project can have at most one Global Exception Handler set at any given time. Any workflow can be flagged as the handler except Main.xaml .
Project Scope Only: The Global Exception Handler can only be created inside standard Automation Process projects. It is not supported in Library projects because libraries are meant to be consumed as modular dependencies where exception bubbling must remain under the control of the consuming workflow.
Activation: Create one from New > Global Handler on the Design ribbon, or right-click an existing workflow in the Project panel and select Set as Global Handler . The Project panel marks the handler with its own icon.
Invocation Trigger: The handler runs when an activity in the project throws an error. UiPath documents two details that surprise many developers:
In nested activities, the handler executes for each activity in the call stack .
It does not execute for activities directly encapsulated in a Try Catch , unless they are contained in another activity. UiPath's note puts it the other way round: when a project uses a Try Catch, group the activities into a Sequence inside the Try container, otherwise the Global Exception Handler does not execute.
So an error thrown by an activity inside a Sequence in the Try block reaches the handler first. The value it returns decides what happens: Continue rethrows the exception, and the enclosing Catch can then handle it.
2. Handler Arguments: errorInfo and result
The interface between the UiPath execution engine and GlobalHandler.xaml is strictly defined by two reserved workflow arguments: +--------------------------------------------------------------------------------+
- | GLOBAL HANDLER ARGUMENT CONTRACT |
- | |
- | [Workflow Engine] ─────► In: errorInfo (ExceptionHandlerArgs) ─────► [GEH] |
- | │ |
- | [Workflow Engine] ◄───── Out: result (ErrorAction) ◄───────────────────+ |
- +--------------------------------------------------------------------------------+
- 1. In Argument: errorInfo ( UiPath.Core.ExceptionHandlerArgs )
The errorInfo argument carries comprehensive diagnostic metadata regarding the failure context:
errorInfo.Exception ( System.Exception ): The exact exception object thrown by the failing activity. Exposes standard .NET diagnostic properties:
errorInfo.Exception.Message : The human-readable error description (e.g., "Cannot find the UI element corresponding to this selector" ).
errorInfo.Exception.Source : The internal source module or activity package that threw the fault.
errorInfo.Exception.StackTrace : The full chronological stack trace indicating the precise execution path leading to the failure.
errorInfo.Exception.InnerException : Any underlying nested exception wrapped by the primary fault.
errorInfo.ActivityInfo : Identifies the activity that faulted:
errorInfo.ActivityInfo.Name : The display name of the activity that threw the exception, which UiPath's own example assigns to a variable and logs.
errorInfo.RetryCount ( System.Int32 ): A zero-based integer tracking how many times the Global Exception Handler has already retried this specific failed activity. On the initial failure, errorInfo.RetryCount equals 0 . If the handler issues an ErrorAction.Retry directive and the activity fails again on the subsequent attempt, errorInfo.RetryCount increments to 1 , then 2 , and so forth.
2. Out Argument: result ( UiPath.Core.ErrorAction )
The result argument is an enumeration value returned by GlobalHandler.xaml to the workflow engine, commanding it on how to proceed.
3. The ErrorAction Enum Directives: Deep Dive
The ErrorAction enumeration defines four distinct directives that dictate runtime behavior following an unhandled error: ErrorAction Enumeration Directives
- ├── ErrorAction.Retry ──► Re-executes the failed activity in-place from scratch
- ├── ErrorAction.Abort ──► Terminates the entire process immediately with a fatal error
- ├── ErrorAction.Ignore ──► Suppresses the error and proceeds to the very next activity
- └── ErrorAction.Continue ──► Rethrows the exception up the standard call stack
- 1. ErrorAction.Retry
Operational Mechanics: Instructs the workflow engine to re-execute the exact activity that failed .
Execution Boundary: The retry occurs strictly at the activity level. The workflow does not restart from the beginning of the workflow file, nor does it re-execute preceding activities in the container sequence.
Retry Counter Behavior: Re-executing the activity increments errorInfo.RetryCount by 1. If the retried activity fails again, the Global Exception Handler is reinvoked with the incremented RetryCount .
Enterprise Best Practice: Never issue ErrorAction.Retry unconditionally; doing so creates an infinite execution loop if an application is permanently unresponsive. Always guard the retry directive with a conditional check against a maximum retry threshold (typically 2 or 3 retries): If errorInfo.RetryCount < 3 Then
- result = ErrorAction.Retry
- Else
- result = ErrorAction.Abort
- End If
- 2. ErrorAction.Abort
Operational Mechanics: UiPath documents Abort as: the execution stops after running the current Global Exception Handler.
Status in Orchestrator: The execution stops after the Global Exception Handler finishes running, and the error ends the job.
Use Case: Used when a permanent, fatal infrastructure failure occurs—such as database connectivity loss, complete application crash, invalid credentials, or when an activity has exhausted its maximum allowable retry count.
Best Practice: Before setting result = ErrorAction.Abort , the handler should execute diagnostic actions: capturing a desktop screenshot, logging a fatal audit entry, and dispatching alert notifications to operations teams.
3. ErrorAction.Ignore
Operational Mechanics: Commands the workflow engine to suppress the exception entirely, skip the failed activity, and immediately proceed to the next activity in the sequence .
Analogy: Identical in behavior to the legacy Visual Basic On Error Resume Next directive.
Critical Architectural Warning: ErrorAction.Ignore is inherently hazardous in enterprise automations. If Activity 1 ( Extract Customer Balance ) fails and is ignored, Activity 2 ( Calculate Tax on Customer Balance ) will execute against an uninitialized or null variable, triggering downstream null reference exceptions or corrupting transactional financial records.
Valid Use Case: Strictly restricted to non-critical, optional side-effects where failure has zero impact on downstream data integrity—such as dismissing an optional promotional banner, closing a non-essential tooltip, or writing a secondary telemetry log.
4. ErrorAction.Continue
Operational Mechanics: Instructs the runtime to rethrow the exception and re-engage the standard exception bubbling hierarchy.
Propagation Behavior: The exception escapes the Global Exception Handler and travels up the call stack. If any higher-level caller workflow contains an enclosing TryCatch block, that outer TryCatch will catch the error. If no parent TryCatch exists, the process terminates fatally with the original exception.
Enterprise Use Case: Used when the Global Exception Handler is utilized as a centralized diagnostic logger (e.g., capturing a timestamped screenshot and writing custom audit metadata to an external SIEM tool), while delegating actual recovery or business decision-making to calling parent workflows.
4. Enterprise Design Patterns for GlobalHandler.xaml
Production implementations of the Global Exception Handler incorporate sophisticated diagnostic and defensive logic: ' Decision logic written as VB.NET for readability. In GlobalHandler.xaml you build it
' with If, Assign, Log Message, and Take Screenshot activities.
- ' Step 1: Capture Diagnostic Screenshot on First Failure
- If errorInfo.RetryCount = 0 Then
Dim screenshotPath As String = Path.Combine(in_LogFolder, $"Error_{errorInfo.ActivityInfo.Name}_{DateTime.Now:yyyyMMdd_HHmmss}.png")
- ' Execute Take Screenshot and Save Image activities
- End If
- ' Step 2: Differentiate Exception Types and Determine Action
- If TypeOf errorInfo.Exception Is UiPath.Core.SelectorNotFoundException OrElse
- TypeOf errorInfo.Exception Is System.TimeoutException Then
- ' Transient UI delay: retry up to 3 times
- If errorInfo.RetryCount < 3 Then
Console.WriteLine($"[GEH RETRY] Activity '{errorInfo.ActivityInfo.Name}' failed. Attempting retry {errorInfo.RetryCount + 1} of 3.")
- result = ErrorAction.Retry
- Else
Console.WriteLine($"[GEH ABORT] Activity '{errorInfo.ActivityInfo.Name}' exceeded maximum retries. Aborting execution.")
- result = ErrorAction.Abort
- End If
- ElseIf TypeOf errorInfo.Exception Is System.Security.Authentication.AuthenticationException OrElse
- TypeOf errorInfo.Exception Is System.IO.FileNotFoundException Then
' Permanent Configuration / Security Fault: Abort immediately without retrying
Console.WriteLine($"[GEH FATAL] Permanent fault encountered in '{errorInfo.ActivityInfo.Name}': {errorInfo.Exception.Message}. Immediate abort.")
result = ErrorAction.Abort
- Else
- ' Unhandled generic system fault: Log and rethrow to parent caller
- result = ErrorAction.Continue
- End If
- Telemetry Enrichment Best Practices
Dynamic Delay Before Retry: To allow an unresponsive application window time to render, insert a short Delay activity (e.g., 2 to 5 seconds) inside GlobalHandler.xaml before assigning ErrorAction.Retry .
Selective Activity Filtering: Inspect errorInfo.ActivityInfo and the exception type. If the failing activity is a sensitive transactional operation (such as Execute NonQuery inserting a ledger line), retrying in-place could create duplicate database records. Filter out non-idempotent activities and abort instead.
Audit Trail Logging: Always log errorInfo.ActivityInfo.Name , errorInfo.RetryCount , and errorInfo.Exception.Message to Orchestrator at the Warn or Error logging level.
5. Architectural Comparison: GEH vs. REFramework TryCatch
Enterprise architects must understand how the Global Exception Handler interacts with the Robotic Enterprise Framework (REFramework) : Architectural Layering: REFramework vs. Global Exception Handler
- +--------------------------------------------------------------------------------+
- | REFramework Process.xaml (Transaction Scope) |
- | +--------------------------------------------------------------------------+ |
- | | TryCatch (Enclosing Business Logic) | |
- | | - Try: Navigate -> Click -> Extract -> Submit | |
- | | - Catch BusinessRuleException: Mark Queue Item 'Failed - Business' | |
- | | - Catch System.Exception: Close Apps -> Init State -> Retry Transaction | |
- | +--------------------------------------------------------------------------+ |
- | * If a GEH is set, it runs first for activities grouped inside the Try. | |
- | * Only if it returns Continue does the local Catch receive the error. | |
- +--------------------------------------------------------------------------------+
- │
- (Runs for activity errors in the call stack)
- ▼
- +--------------------------------------------------------------------------------+
- | GlobalHandler.xaml (Process Safety Net) |
- | - Decides Retry, Ignore, Continue, or Abort for the failing activity |
- | - Activity-level retry in place (no app restart) |
- | - Final safety barrier before unexpected robot crash |
- +--------------------------------------------------------------------------------+
- Key Differences Table
- Architectural Dimension Global Exception Handler (GEH) REFramework Process.xaml TryCatch
- Architectural Scope Process-wide global safety net Local transaction boundary
Interception Point Runs for the failing activity (and each activity in the call stack) and returns an ErrorAction Exceptions thrown inside the Try block of the transaction
Retry Granularity Activity-level: Retries the single failing activity in-place Transaction-level: Restarts applications and retries the entire transaction
Application State Recovery No application reset (leaves UI in current state) Executes CloseAllApplications / KillAllProcesses and returns to Init
Queue Item Impact Does not interact directly with Orchestrator queues Updates Queue Item status ( Successful , Failed , Retried )
Typical Target Unattended desktop glitches, unattended process crashes Business logic validation, API failures, transactional data faults