Best Practice: Do you regularly utilize Try Catch on the whole workflow?



Wanted to get a feel for how others are dealing with unexpected exceptions.

The keyword here is “unexpected”.

Any robot we develop must ultimately start with some kind of top level container (i.e. usually a sequence or flowchart). If an unexpected exception occurs within the various nested workflow steps, if we didn’t already use a Try/Catch around that activity (i.e. expecting an error)… users will see the big, often intimidating error dialog in their faces when the robot dies due to the fatal unexpected/unhandled exception.

Often we include Try/Catch within various nested workflows to catch known & expected errors… but I’m wondering whether any of you also use a Try/Catch Activity as the topmost container to more elegantly deal with unhandled (unexpected) exceptions?



  • For projects under development is not recommended to use try catch block as u wont know were the error occur and actually when i occur while ur run ur bot during the development.

  • During development well need to correct those errors right so it safe to insert try catch block after u make sure that small validative errors dont occur.

  • After u finish developing the bot and correct all the notifiable errors then put try catch and dont forget to add logs to the catch blocks.

  • Since log are very important to know what error are cached by the catch block so u can make the changes required in the bot.

Thanks and Regards


Thanks. Not really sure I agree with that.

My question was about putting a Try/catch on the whole workflow simply to handle ALL “unhandled” exceptions thrown by nested activities the same way. It could log them, maybe send an urgent text or email to support people, then display the exception message in a more friendly way. I’ve never found the stack traces in the default “unhandled exception” dialog to be very insightful anyway… certainly not for the end users.

Regardless of whether we do or don’t add a try/catch to the topmost activity during development… exceptions will still be thrown… it’s just that we could handle unexpected fatal exceptions in a way that is more pleasant & effective instead of letting UIPath’s default error dialog appear.

I wasn’t recommending that we just swallow all the exceptions, only that we handle any unexpected fatal exceptions in one elegant, centralized way :slight_smile:

That also doesn’t mean I wouldn’t sprinkle some try/catch into nested activities to deal with non-fatal exceptions… just that I would handle unexpected exceptions with 1 central mechanism up top and try to make them look less intimidating to end users.


Following Raguvarthan, I think it is obvious that during development and test we make sure the automation is stable, and after that include Try Catch only on sequences with less volatility (like activities that depends on the environment). But it really bother me, should I also put more lovel on it, and put the whole automation into a Try Catch block? I see no demerit on it by now. Any other opinion?


Yes… obviously “stable” is convenient, but in the real world… unexpected things can happen in a production environment.

I’m talking about building in an opportunity to further process unexpected/unhandled exceptions. We can’t possibly anticipate & trap every exception that might occur, so maybe we want to do something special when unexpected fatal errors occur (i.e. suppress/replace the big ugly default error dialog with something more elegant, send an early warning email or text notification to a critical support person, etc.)


The closest thing I have done to wrapping a whole workflow in a try catch was on a current project I did wrap a large piece of a workflow in a try catch because the web application it interacts with is only so stable/reliable so I needed a way to compensate for it not responding or taking too long to render something. If an action fails in trying to find a particular element or something it’ll error out and try and move on to the next record to try and process it. Other than that I tend to wrap only specific areas in try catches based on testing results or expected errors.


I use (and I believe it’s actually the best way) one outer Try/Catch container for each portion of the project. I will occasionally use Retry Scopes inside that for parts that are known inconsistent.

So here are the basic steps:

  1. Initialize global settings to a dictionary or variables, surrounded by Try/Catch

  2. enter either Get item number or Process stage, surrounded by Try/Catch to capture error, take screenshot, log exception.Source+exception.Message to file and Log Message, kill applications

  3. increment retry counter, continue where it left off

  4. enter Closure sequence if maxretries happen or Process is complete

I’m still evolving how this works to be the simplest possible.