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.
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
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:
Initialize global settings to a dictionary or variables, surrounded by Try/Catch
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
increment retry counter, continue where it left off
enter Closure sequence if maxretries happen or Process is complete
I’m still evolving how this works to be the simplest possible.
Not to be too lazy, but you can check out the ReFramework which is now a feature in Studio. While I don’t necessarily believe it is put together very well, it still shows how you would go about designing initialization, error handling, and closure.
The best approach to have robust exception handling in your program is to use the ReFramwork and copy all your .xml files in the process transaction block. One slight customization you can make is to separate business and system exceptions in the framework to better help you debug the issues.
Can you shed more light on the 2nd part of this statement? What does it mean to “copy all your .xml files in the process transaction block”?
Do you mean to take a project that was first created without ReFramework, and copy all of its logic into a new ReFramework project’s “process transaction” work block?
Yes. You need to use a project create using the delivered ReFramework, there is a process.xml file. You need to invoke all your existing .xml from there.
Ignoring the failure of validation and business rules makes no sense. The inclusion of exception handling (try-catch) should be included in the initial framework, as well as retry and timeout values.
Much more effort should be given by UiPath into serious training videos and documentation of multi-layer exception handling. This shouldn’t be considered an optional component.Other vendors spend almost half of their initial training on exception handling.
Your question boils down to catching unknown exceptions. Like in other languages we have if other… something like KnownException1, KnownException2,…OtherExceptions.
Looks like there is no way to use this “all other exceptions” concept in UiPath. I think Global Exception Handler is the only way to exit elegantly. You can abort with a message
A try/catch activity allows us to specify which specific, named/typed exceptions we’d like to trap in the catch, and we can do something special for each of those. It also allows us to trap a plain “Exception” (i.e. any exception).
If we place this at the end of our chain within the catch, that block will catch “all other exceptions” than the ones you specified above it.
I know this is an older post but I wanted to chime in here! I’m a software engineer, and, more recently, an RPA Engineer and have done a few end to end automations for the US govt. It’s different for every client, but their code review typically asks for ‘try/catch on all workflows.’ Obviously the goal is to make them as robust as possible, but before the bot goes to UAT after development increment is finished, i do wrap all workflows in try/catch with Log Message, throw, and terminate workflow since another requirement is that if the bot throws a system error at any point, the bot should shutdown. I usually insert a block relevant message and also add exception.Message just to log errors more specifically.
Not necessarily certain if this is best practice, but it is what they require for code review sometimes. Hope this helps!
It would be always suggested to use Try/Catch blocks on each workflow and throw the user defined text with system exception - which will be useful during the fault/bug investigation process.
We continuously add functionalities to the existing build robots and it leads to multiple process and workflows – During the execution if there is an issue occurred – it will be difficult to point out/navigate the issue with minimal information.
For easy trace of the workflow and the activity - exception should contain the workflow and exception message. Example: "Exception Occurred in ABC Workflow, Exception is " +exception.Message.
+1 to octechnologist asking intelligent questions (that are clearly above a number of members of this forum)
+1 to wrapping any and all workflows in exception handling AS WELL AS putting them inside any workflow as needed
I believe that any and every external interface to your process (source data points, configuration items, etc) needs to be treated like its possibly radioactive. Its the same with any application your using. And even if it is working today, any external interface can change tomorrow.
Sometimes unexpected things happen (like upgrades to browsers that break your code)
I found my way here as I am looking for more information on how the global exception handler can break the try…catch mechanism inside a process. That global exception handler is also a good solution to the OP question.
Hi! there is no rule of best practice how big or small the try block should be. In the try block, you need to put whatever operation you want to achieve.
Try-catch block should be used no matter if you use REFramework or not. REFramework exception handling is not to handle all the exceptions that you have in the robot. For more details how you implement this, check the videos below.
I made a video where I explain this specifically of how you implement try-catch in components: Also, if you want to see how you can integrate this with REFramework, check the part 2:
sharazkm32
ashokkarale
prashant1603765
esongi_park
Praveen8008
Aakash_Lad