#BetaBlogs 18.4 - Global Exception Handler



We have improved the debugging options in 18.3 but we didn’t stop there. In Studio there were still few options to inspect an exception in a workflow when an error occurs (Try Catch was a life saver so far). So your feedback helped us come up with the Global Exception Handler.

What is it?

Some workflow executions might fail from unforeseen events that can happen at any time, i.e. application pop-ups, automated updates, OS notifications etc.This feature will help you execute a workflow/logic every time an execution error occurs. Let’s call this a Global Handler.

Why do you need this?

The end benefit of defining a Global Exception Handler and attach it to any process execution is that you can design “recovery blocks” where you can try to clean up after the failure and then choose to Ignore the exception, Retry, or Continue the execution. This feature applies to both debug and runtime. During debug you also have an extra option to Break and inspect the issue.

RPA Developers’ job will be easier with this feature since the handler only needs to be defined once and, unlike the Try Catch blocks, does not need to be attached to each activity. It will execute every time an activity fails to execute.

TL;DR: Imagine that you know you have a pesky pop-up that appears once in a while on your desktop which renders the execution to a halt and failure. You can add logic in the handler to remove the pop-up, when that happens, and then continue the execution from the activity which failed by retrying that exact step.

How does it work?

After creating a Process, you can create a Global Exception Handler from the Design tab - New:

The entry point of a Process (usually Main.xaml) cannot be declared as an exception handler. A new sequence template will be created when you add a new global handler, guiding you to best practices to use the Global Exception Handler. This is how it looks like:

The handler will execute every time an exception occurs both during debug and during runtime. During debug, Studio will ask to choose from one of the Break/Continue/Ignore/Retry options. During runtime, this option can be set inside the handler via “ErrorAction” (see snapshot above). Studio Debug options are:

  • Break: suspends the current execution so that you can inspect what happened
  • Ignore: continues execution from the next activity
  • Retry: will retry executing the current activity
  • Continue: will execute the global handler (which will be executed during runtime as well, when set)

There are a few other behaviors in place which you need to know. As said above, this only applies to Processes, not Libraries. In this case, if an exception occurs in an activity:

  • If it’s surrounded by a Try Catch block, execution continues inside the Catch block as before.
  • If Global Exception Handler is NOT defined for your Process, execution suspends right where the activity threw the exception and you can choose to Retry, Ignore, Continue or Break the execution.
  • Any xaml (that is NOT the entry workflow) can be Set as Exception Handler from the contextual menu in Project panel.
  • There can be only one handler per process.

2018.4 Community Beta Release
2018.4 Community Beta Release
Tackling with unexpected pop-ups in the automation process

Neat that everyone seems to prefer the dark theme (I’ll never understand why :-), but for official threads & documentation, can you please use the light theme? Dark screenshots like that are much harder to read, and I pity the printer of anyone who wants to print a UiPath thread or doc page…


You’re not cool unless you use Dark themes. :laughing:


Agreed. Though I do appreciate the UiPath team for considering and delivering a darker theme, I personally still prefer the lighter one, and I’m one of those people who really wanted to like it, but that just didn’t happen (so far at least.) I guess that’s probably because once you use the tool with a specific theme for some time, it kind of grows on you.


Team any suggestion on pause and resume feature. cant find this functionality.



It looks like that when you remove the exception handler from the project, the studio will break (debug or not) on every exception, even the ones handled by a Try catch.

Is there something planned to safely remove one handler from project?

Edit : This is actually already implemented and issue do not occur if you use “Remove handler” feature.

What I described is happening only if you remove file from Windows explorer.



Agreed. @ovi FYI. Going forward we’ll use Classic Theme for posts. Note that the Dark Theme will be an experimental feature in 18.4.


@Florent_Salendres thanks for the feedback, i’ll get back to you on this.


Pleasure is mine.
Note that all worked out again when removing the Global handler reference inside the project.json (under runtile settings) file



I do not agree. I agree for the official documentation. The forum is not meant to be printed and I would not expect the guys posting to switch their theme every time they are posting something. I would make it free for all.