Study guide
10.3 TryCatch, Retry Scope & Custom Exception Architectures
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.3 TryCatch, Retry Scope & Custom Exception Architectures
Key Takeaways Explain This Topic AI
Try Catch runs the Try block, then the most specific matching Catch, and always runs Finally.
The Try Catch activity chooses the most specific matching Catch regardless of list order, but listing specific types before System.Exception keeps the workflow readable.
Rethrow, which is allowed only inside a Catch, preserves the original exception and stack trace, while Throw raises a new or reset exception.
Custom exception classes belong in C# code source files or referenced libraries; deriving from BusinessRuleException keeps REFramework's business path working.
Retry Scope runs its Action and Condition up to NumberOfRetries times (default 3, counting the first attempt) with a RetryInterval pause (default 5 seconds).
Last updated: September 2026
10.3 TryCatch, Retry Scope & Custom Exception Architectures
Core Concept: Building enterprise-grade, resilient automations requires a structured, multi-layered exception handling architecture. UiPath Studio provides robust language-level and framework-level constructs—chief among them the TryCatch container, the lightweight Retry Scope , and the ability to define strongly typed Custom Exceptions . Mastering the precise execution mechanics of these tools, maintaining stack trace integrity via Throw vs. Rethrow , and enforcing strict catch block inheritance hierarchies prevents unhandled faults from corrupting business data and ensures rapid, auditable incident remediation.
In unattended automation environments, software robots operate without direct human supervision. When an ERP interface experiences latency, a database connection drops, or a business document violates processing guidelines, the automation must detect, categorize, isolate, and respond to the fault deterministically. Relying on default unhandled behavior results in orphaned system sessions, corrupted transactional records, and inflated mean-time-to-resolution (MTTR).
1. The TryCatch Activity: Architecture & Execution Mechanics
The TryCatch activity is the fundamental building block of defensive programming in UiPath Studio. Modeled on Microsoft .NET structured exception handling, it encapsulates failure-prone logic and routes execution through dedicated recovery pathways. +--------------------------------------------------------------------------------+
- | TRYCATCH CONTAINER |
- | |
- | +--------------------------------------------------------------------------+ |
- | | TRY BLOCK: Primary execution sequence containing risk-prone activities. | |
- | | - Read Transaction Data from Remote API | |
- | | - Write Transaction Record to SQL Database | |
- | +--------------------------------------------------------------------------+ |
- | │ |
- | (If an exception occurs during Try) |
- | ▼ |
- | +--------------------------------------------------------------------------+ |
- | | CATCHES: Typed handlers; the most specific matching type runs. | |
- | | - Catch [BusinessRuleException]: Log validation fault & notify user | |
- | | - Catch [System.Data.SqlClient.SqlException]: Log DB fault & rollback | |
- | | - Catch [System.Exception]: Universal fallback for unhandled technical | |
- | +--------------------------------------------------------------------------+ |
- | │ |
- | (Executes unconditionally) |
- | ▼ |
- | +--------------------------------------------------------------------------+ |
- | | FINALLY BLOCK: Resource cleanup and state finalization. | |
- | | - Close SQL Database Connection & Release File Locks | |
- | +--------------------------------------------------------------------------+ |
- +--------------------------------------------------------------------------------+
- The Tripartite Architecture
Try Block: Houses the primary workflow activities intended for normal execution. If all activities within the Try block complete successfully, execution skips all Catches handlers and proceeds directly to the Finally block. The moment any activity in Try throws an exception, execution immediately halts within Try and transfers to Catches .
Catches Block: A collection of one or more typed exception handlers. When an exception occurs, the activity chooses the Catch whose type matches the thrown exception exactly, or else the most specific type the exception inherits from. That Catch runs its recovery logic (e.g., logging errors, setting status variables, performing rollback routines).
Finally Block: Contains cleanup and finalization logic that executes unconditionally upon exiting the TryCatch construct. The Finally block executes under all possible exit scenarios:
When the Try block completes with zero errors.
When an exception occurs in Try and is caught and handled by a Catch block.
When a Catch block executes a Rethrow or Throw activity.
Even when an unhandled exception escapes a Catch block, Finally executes before the exception bubbles up to parent scopes.
Enterprise Use Case: Closing active file streams, disposing of database connections, resetting temporary environment variables, or releasing application semaphores.
.NET Exception Inheritance & The Order of Catches
All exceptions in UiPath Studio derive from the base .NET class System.Exception . Understanding this class hierarchy is paramount when configuring multiple Catch handlers: .NET Exception Inheritance Hierarchy in UiPath
- System.Object
- └── System.Exception (Universal Base Class)
- ├── UiPath.Core.BusinessRuleException (Domain Validation Errors)
- └── System.SystemException (Technical & Operating System Errors)
- ├── System.IO.IOException
- │ ├── System.IO.FileNotFoundException
- │ └── System.IO.DirectoryNotFoundException
- ├── System.Net.WebException (Network & HTTP Faults)
- ├── System.Data.Common.DbException (Database Connection Faults)
- └── System.NullReferenceException (Uninitialized Variable Faults)
- How the Try Catch Activity Picks a Catch
UiPath's Try Catch activity comes from Windows Workflow Foundation. When an exception is thrown, it looks for the Catch whose exception type matches the thrown type exactly, and otherwise for the most specific Catch type that the exception inherits from. UiPath's own tutorial puts it this way: the Catches always match the most specific exception first, even when a generic System.Exception Catch is also present.
Order does not decide the winner. A System.IO.FileNotFoundException is handled by a FileNotFoundException Catch even if a System.Exception Catch appears above it in the list.
Still list them from specific to general. Readers of the workflow expect that order, and it matches how you would write the code in C# or VB.NET, where the order of catch clauses does matter.
Typical list:
- Catch [UiPath.Core.BusinessRuleException] (domain business rule violations)
- Catch [System.IO.FileNotFoundException] (a specific missing file)
- Catch [System.IO.IOException] (broader disk errors)
- Catch [System.Exception] (the fallback for anything else)
- 2. Stack Trace Integrity: Throw vs. Rethrow
In enterprise production environments, rapid incident diagnosis depends on the clarity of exception logs. The UiPath workflow runtime records an exception's origin via its StackTrace , which captures the chronological call hierarchy, workflow filenames, container activities, and exact line numbers where the fault originated. +--------------------------------------------------------------------------------+
- | THROW VS. RETHROW EXECUTION DYNAMICS |
- | |
- | Scenario: Error occurs in Workflow 'SubmitInvoice.xaml' at Activity 'Click' |
- | |
- | Approach A: Throw ex (ANTI-PATTERN) |
- | [Catch ex] ──► [Throw ex] |
- | * STACK TRACE DESTROYED: Stack trace resets to the 'Throw' activity inside |
- | the Catch block. Diagnostic visibility into 'SubmitInvoice.xaml' is lost! |
- | |
- | Approach B: Rethrow (ENTERPRISE STANDARD) |
- | [Catch ex] ──► [Rethrow] |
- | * STACK TRACE PRESERVED: Preserves the original failure site in |
- | 'SubmitInvoice.xaml' at Activity 'Click', including inner exceptions! |
- +--------------------------------------------------------------------------------+
- The Throw Activity
Operational Mechanics: Instantiates and raises a brand-new exception object into the execution pipeline.
Stack Trace Reset: Executing a Throw activity sets the exception's originating StackTrace to the location of the Throw activity itself.
Primary Use Cases:
Raising a BusinessRuleException when a data validation rule is breached (e.g., Throw New BusinessRuleException("Invoice total cannot be negative.") ).
Translating a low-level technical exception into a domain-specific custom exception.
Critical Anti-Pattern ( Throw ex ): A frequent mistake made by novice developers is catching an exception variable ex inside a Catch block and then executing a Throw activity with Value = ex . This practice wipes out the original stack trace and resets the error origin to the Catch block itself, blinding support teams to the true root-cause activity.
The Rethrow Activity
Operational Mechanics: Re-elevates the exact existing exception currently being handled within a Catch block, propagating it upward to the calling workflow.
Scope Constraint: The Rethrow activity can only be placed inside a Catch block of a TryCatch activity. Placing it anywhere else produces a validation error in Studio.
Stack Trace Preservation: Unlike Throw , Rethrow leaves the original exception object, its inner exceptions, and its entire call stack completely intact.
Enterprise Role: Essential when a sub-workflow needs to perform local remediation or logging (such as taking a diagnostic screenshot or logging a local warning) before allowing the calling parent workflow (such as REFramework's Process.xaml ) to handle the transaction-level failure.
3. Creating Custom Exception Architectures
While standard .NET and UiPath exceptions cover technical system faults and basic business rule failures, complex enterprise processes benefit significantly from Strongly Typed Custom Exceptions .
Why Define Custom Exceptions?
Semantic Clarity: Differentiating between distinct business failure modes (e.g., VendorValidationException , CreditLimitExceededException , DuplicateInvoiceException ) rather than relying on generic string parsing of exception messages.
Granular Catch Handling: Workflows can declare dedicated Catch blocks for specific business conditions, applying tailored recovery logic (such as routing a transaction to a specialized human review queue in Action Center) without capturing unrelated business exceptions.
Implementing Custom Exceptions in UiPath
Custom exception classes can be implemented in a C# code source file inside the project or in an external class library referenced as a package. Invoke Code bodies cannot declare classes. // Enterprise Custom Exception in C# (Coded Workflow / Class Library)
- using System;
- using UiPath.Core;
- [Serializable]
- public class VendorValidationException : BusinessRuleException
- {
- public string VendorTaxID { get; }
- public decimal InvoiceAmount { get; }
- // Standard constructor
- public VendorValidationException(string message) : base(message) { }
- // Enriched diagnostic constructor
- public VendorValidationException(string vendorTaxId, decimal amount, string message)
- : base($"Vendor Validation Failed for Tax ID '{vendorTaxId}' (Amount: {amount:C}): {message}")
- {
- this.VendorTaxID = vendorTaxId;
- this.InvoiceAmount = amount;
- }
- } ' Custom exception in a referenced VB.NET class library
- <Serializable>
- Public Class DatabaseTimeoutException
- Inherits System.Exception
Public Property TargetDatabase As String
- Public Sub New(dbName As String, message As String, inner As System.Exception)
- MyBase.New($"Database operation timed out on '{dbName}': {message}", inner)
- Me.TargetDatabase = dbName
- End Sub
- End Class
- 4. The Retry Scope Activity: Transient Fault Resilience
While TryCatch provides full control over exception handling, using it to implement retry loops introduces substantial visual clutter and maintenance overhead (requiring variables for loop counters, retry delays, and exit flags). The Retry Scope activity encapsulates this pattern into a lightweight, high-performance container. +-------------------------------------------------------------------------------+
- | RETRY SCOPE CONTAINER |
- | NumberOfRetries: 3 | RetryInterval: 00:00:05 | ContinueOnError: False |
- | |
- | +-------------------------------------------------------------------------+ |
- | | ACTION BLOCK: Logic to execute and retry upon failure. | |
- | | - Click 'Download Monthly Report' Button | |
- | +-------------------------------------------------------------------------+ |
- | │ |
- | ▼ |
- | +-------------------------------------------------------------------------+ |
- | | CONDITION BLOCK: Validation activity returning Boolean or UI State. | |
- | | - File Exists 'C:\Reports\MonthlyReport.pdf' | |
- | +-------------------------------------------------------------------------+ |
- +-------------------------------------------------------------------------------+
- Execution Lifecycle of Retry Scope
The Retry Scope consists of two distinct functional compartments:
Action Block: Contains the sequence of activities that perform the target operation.
Condition Block: Contains an activity that validates whether the action achieved its desired outcome. The activity placed in this block must either return a Boolean variable or implement condition verification (e.g., Element Exists , Check App State , File Exists ).
Operational Rules & Evaluation Flow
Action Execution: The runtime executes the Action sequence.
Condition Evaluation: If the Action completes without throwing an exception:
The runtime evaluates the Condition block.
If the Condition evaluates to True (or if no Condition is specified and Action completed without errors), the Retry Scope exits successfully.
Retry Trigger: If the Condition evaluates to False , OR if an unhandled exception is thrown anywhere inside the Action or Condition blocks:
The runtime catches the failure internally.
It pauses execution for the duration specified in the RetryInterval property.
It increments the internal retry attempt counter.
It re-executes the Action block from the beginning.
Exhaustion & Fault Propagation: If the configured NumberOfRetries attempts are used up without success, the Retry Scope throws an exception, unless Continue On Error is set to True. The first attempt counts toward the number, so the default of 3 means at most three executions of the Action.
Key Configuration Properties
NumberOfRetries ( Int32 ): The number of attempts (default 3 ). UiPath's own example sets it to 3 and describes that as attempting the action three times.
RetryInterval ( TimeSpan ): The pause between attempts; the default is 5 seconds . Lengthen it when the system you are waiting on needs more time to recover.
ContinueOnError ( Boolean ): If set to True , suppresses the final failure exception when retries are exhausted, allowing parent workflows to proceed. Default is False .
5. Enterprise Defensive Architecture & Fault Tolerance Comparison
Enterprise robotic automations integrate multiple layers of defense to establish self-healing capabilities: Multi-Layered Enterprise Fault Tolerance Architecture
- Level 1: Transient UI / Network Layer ──► Retry Scope (Atomic In-Place Retries)
- Level 2: Transaction Boundary Layer ──► REFramework TryCatch (Process.xaml)
- Level 3: Global Safety Net Layer ──► Global Exception Handler (GlobalHandler.xaml)
- Level 4: Orchestrator Queue Layer ──► Queue Auto Retry (Max # of retries)
- Architectural Comparison Table
Feature / Dimension TryCatch Retry Scope Global Exception Handler REFramework Queue Retry
Operational Scope Activity block or transaction scope Atomic UI / network operation Entire automation project Entire transaction item
Interception Method Catches exceptions explicitly by type Catches any error or unsatisfied condition Runs for activity errors in the call stack and returns an ErrorAction Catches exceptions escaping Process.xaml
Retry Granularity Manual (requires custom looping logic) In-place atomic retry of Action block In-place retry of failed activity Full transaction retry from Init state
Condition Checking Based on exception type matching Explicit Condition activity verification Evaluates errorInfo.RetryCount & metadata Evaluates in_TransactionNumber & retry limits
Application State Recovery Custom recovery logic in Catch/Finally None (assumes transient glitch) None (retries activity in current state) Restarts all target applications cleanly
Primary Enterprise Role Transaction boundaries, resource disposal Polling file creation, transient UI clicks Emergency project safety net & logging Resilient, distributed transaction processing