You put the risky activity inside Try Catch, add a matching exception type, and write your recovery. Then you add a Global Exception Handler. Suddenly the robot retries the activity and stops without reaching your local Catch.

It's tempting to rebuild the catch or assume Studio has lost track of the scope. Check the global handler first.

This resurfaced in Exception not getting caught. Earlier reports describe local catches apparently being bypassed and a download process retrying and exiting instead of recovering locally. They establish a recurring source of confusion, not a confirmed diagnosis for every affected project.

The name doesn't tell the whole story

The Global Exception Handler docs explain that, with nested activities, the handler executes for each activity in the call stack. Activities directly inside Try Catch are treated differently from activities nested inside another container.

These layouts therefore aren't interchangeable when investigating handler execution:

Try Catch Try Failing activity 
Try Catch Try Sequence Failing activity

These are layout sketches, not executable workflow code. UiPath recommends a Sequence inside Try when using the global handler with Try Catch so the global handler executes. Adding that container isn't a blanket fix to make your local catch run first.

Read the result literally

The handler's result argument controls what happens next:

  • Continue rethrows the exception.
  • Ignore ignores it and continues from the next activity.
  • Retry retries the activity that failed.
  • Abort stops execution after the handler runs.

For a VB project, the rethrow choice can be set with an Assign activity, targeting result with the value ErrorAction.Continue. Written as an assignment:

result = ErrorAction.Continue

This is a branch choice, not a complete handler or a universal replacement for your stopping policy.

The important distinction is Continue versus Ignore. “Continue” here doesn't mean successful recovery. It means the error is rethrown. “Ignore” doesn't forward the error to your catch.

If your design needs an enclosing, matching Catch to handle the failure, inspect the handler branch that returns Abort. Test the Continue rethrow path in an isolated copy before changing the shared handler. Don't replace every abort with continue without deciding which errors should still stop the process.

Rule out the separate silent-error setting

The Try Catch activity docs state that no error is caught if an activity in Try has ContinueOnError set to True. Check it where the failing activity exposes the property. That's different from a global handler returning Ignore, even if both leave you wondering why your catch didn't run.

A useful reproduction keeps the container layout unchanged and varies one handler result at a time. Compare the route through the global handler and local catch before restoring the real recovery steps. That gives you evidence instead of another round of catch-type guessing.

Have you hit this in an existing process? Share the layout and handler result in the original forum thread.

Originally posted on the UiPath Forum: https://forum.uipath.com/t/uipath-pitfall-of-the-week-5-expecting-try-catch-to-run-before-the-global-exception-handler/5788632

I post short UiPath fix videos from real forum questions on my YouTube channel, RPA Simplified.