Why Every UiPath Project Needs a Global Exception Handler
Imagine this: one of your coworkers makes a massive UiPath project with tens of workflows and hundreds of activities. This automation goes live, but later on the business informs you that they received an error email, and you've been asked to debug this automation. Unless your coworker was incredibly diligent and thorough with their exception messages, odds are that you'll need to search through tens of workflows and hundreds of activities to find which activity failed.
In my experience debugging UiPath automations, finding the activity that failed is easily the most time-consuming part. After I identify the failed activity, finding the problem and developing the fix usually isn't too involved. But hunting down failed activities can be quite the tedious, draining chore. Thankfully there is a way to get rid of this chore and make debugging much quicker: using the Global Exception Handler in your project.
What is the Global Exception Handler? To quote UiPath's documentation:
The Global Exception Handler is a type of workflow designed to determine the project’s behavior when encountering an execution error. Only one Global Exception Handler can be set per automation project.
This article describes the Global Exception Handler well and is worth reading, but I don't think this article emphasizes enough just how powerful this feature is.
The documentation mentions the errorInfo and result arguments. I don't have too much to say about result; the documentation covers it all. But I would personally recommend not modifying result, because if you modify it, some activities could be aborted, ignored, or retried when you don't want them to.
errorInfo on the other hand is much more interesting. It has several worthwhile properties, some that the documentation doesn't even mention:
- ActivityInfo: the ID, name, and type of the failed activity
- Arguments: the names and values of all the activity's arguments
- Exception: the exception object
- RetryCount: how many times the activity was retried using ErrorAction.Retry
- Variables: the names and values of all the workflow's variables
- WorkflowArguments: the names and values of all the workflow's arguments
At an absolute minimum, the Global Exception Handler should log the ID, name, and type of the failed activity. With this, developers can look in Orchestrator logs to find which activity failed right away, eliminating the chore of tracking it down manually. This log message alone makes a big difference in any project.
But to really make the most of the Global Exception Handler, listing Arguments, Variables, and WorkflowArguments will give debuggers every bit of information they could possibly need. Maybe the cause of the failure was simply that a value was wrong, possibly due to a typo or an incorrect .NET expression. If this info is immediately available to debuggers, they may be able to immediately identify the issue without even testing the bot.
If it wasn't clear by this point, exception handling and reporting is something I'm passionate about, because debugging is the only thing I dislike about automation development. And anything I can do to lessen the time I have to spend debugging results in more time spent developing new things.
For this reason, I decided to make some UiPath frameworks that make heavy use of the Global Exception Handler. In these frameworks, any exceptions that occur are caught by the Global Exception Handler and archived in emails, Excel reports, and Action Center form tasks, so debuggers have several ways to find every bit of exception info possible.
If you decide to download this framework, feedback is always welcome! I'm always open to ideas to improve these frameworks further.
