Local TryCatch Bypassed by Global Exception Handler in UiPath Studio 25.0.157

I am encountering an issue in UiPath Studio where exceptions thrown within a TryCatch block in Main.xaml are not being caught by the local Catch block and are instead handled directly by the GlobalHandler.xaml. This behavior contradicts the expected functionality, as the TryCatch is properly configured to catch System.Exception, and the activities are grouped in a Sequence inside the Try block, per the UiPath documentation (Studio - Global Exception Handler).

Environment

  • UiPath Studio Version: 25.0.157-cloud.18912 (cloud-based build)
  • Project Compatibility: Windows
  • Expression Language: C#
  • Dependencies:
    • UiPath.System.Activities: 24.10.7
  • Target Framework: Windows

Steps to Reproduce

  1. Create a new UiPath process with Main.xaml and GlobalHandler.xaml.
  2. In Main.xaml:
  • Add a TryCatch activity.
  • Inside the Try block, add a Sequence containing:
    • A Log Message to indicate the start of the Try block.
    • Two Assign activities to simulate a NullReferenceException:
      • sampleString = Nothing
      • output = sampleString.ToString()
  • In the Catches section, add a Catch for System.Exception with a Sequence containing:
    • A Log Message to log the exception details (exception.GetType().ToString() + " - " + exception.Message).
    • A Log Message to confirm the exception was handled.
  • In the Finally block, add a Sequence with a Log Message to indicate the Finally block was reached.
  1. In GlobalHandler.xaml:
  • Configure as the global exception handler with errorInfo (In) and result (Out) arguments.
  • Add a Sequence with:
    • A Log Message to log errorInfo.Exception.ToString.
    • An If activity to retry up to 3 times or abort.
  1. In project.json, set exceptionHandlerWorkflow to GlobalHandler.xaml.
  2. Run Main.xaml in Debug mode with breakpoints in:
  • The Try block’s Log Message and Assign activities.
  • The Catch block’s Log Message activities.
  • The Finally block’s Log Message.
  • The GlobalHandler.xaml’s Log Message.

Expected Behavior

  • The Assign activity (output = sampleString.ToString()) throws a NullReferenceException.
  • The local TryCatch in Main.xaml catches the exception in the Catch block for System.Exception.
  • The Catch block logs the exception details and the “handled” message.
  • The Finally block executes, logging its message.
  • The GlobalHandler.xaml is not invoked, as the exception is caught locally.

Hey @asif.islam here is the solution to handle this When a Try-Catch block contains multiple activities, and an exception is thrown within the Try block, the GEH may intercept the exception before it reaches the Catch block. This occurs because the GEH is designed to handle uncaught exceptions globally, and its execution can bypass local exception handling mechanisms.

cheers

1 Like

The UiPath Global Exception Handler does not function as a global exception handler, its incorrectly named in my opinion.

It functions as a ‘first chance exception handler’ and is only fit for logging in my opinion. I would recommend against using it, if you have a large stack, even if its in a try catch, the exception handler will fire on every activity as it bubbles up through the stack, which can be super messy and bad if you also want retries.

2 Likes

@asif.islam

Welcome to the community

the current behavior also might not be what you mentioned as per the behavior it would trigger soon after the exception before reaching catch itself and then the catch block will come into picture

if you see the note as well if a sequence is present then GEH executes first and if that is not present and say a single activity without sequence is there in try catch that is when GEH would not come into picture

Hope this is clear

cheers

This note in their documentation describes a First Chance Exception Handler btw, not a global exception handler, hence my claim that its named incorrectly and therefore not very useful.

I do remember seeing that UiPath had been working on some stuff with their exception handlers last year I think, but I guess Agentic stuff perhaps pushed back the priority, maybe we’ll see improvements soon.

@Jon_Smith

agreed with you on the point

the note was given here to clarify @asif.islam point about it not being caught ideally it would have been

cheers

@Anil_G 100% Anil, the documentation reference was a nice addition. Was just trying to get ahead of anyone claiming it was working as global exception handler, not a first chance one, since the documentation does describe the current behaviour.