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

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.

10 Likes

Hi @ClaytonM,

Would you mind sharing an xaml example of these steps?

Hi.

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.

:no_mouth:

5 Likes

Hello,

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.

I agree octech…(I lilke ClaytonM’s approach)

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.

3 Likes

Try using Global Exception Handler. It can catch any unexpected exception throughout the project.
https://studio.uipath.com/docs/global-exception-handler

2 Likes

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

Sure there is.

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.

3 Likes

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!

3 Likes

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.

Cheers!

+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:

Hi guys, thanks for all your contributions to this topic, especially @octechnologist and @ClaytonM.

I want to revive this thread because as RPA is evolving, so should our best practices and frameworks. With more automated processes and more robots come different challenges, so this post is regarding flexible and scalable exception handling in rapidly changing IT-environments.

Consider this:
A new and unexpected exception comes up in a system used by a lot of robots. Robots cannot recover from this by simply restarting within the ReFramework. A human can log on to the machine and perform a workaround, but the error might come again the next day. IT can’t help and so your robotics operations team is stuck handling the same error on several machines to keep things running. This takes a lot of time.

Now, robots should be able to perform the workaround themselves, but due to the high number of processes it takes plenty of time to implement the workaround and republish for every process. Also, if one thing is for sure, it is the next (major) exception will always be coming! The exception handling should be flexible and scalable!

One idea is to publish an ExceptionHandling workflow to Orchestrator as a library and then use this library in all processes to - obviously - handle exceptions if they occur. When the next exception comes up, the robotics team can update the ExceptionHandling library to include a workaround for the new exception, publish to Orchestrator and use the Mass Project Dependencies Update Tool to equip all the processes with the new ExceptionHandler.

This way your robo operations can quickly react to global issues in the IT environment and implement a fix for all your robots with comparatively little work.

Do you guys have experience and/or best practices with some kind of flexible and scalable exception handling? What do you think of the scenario explained above? Am I missing anything? I’m excited for your feedback.

Thanks,
Lukas

2 Likes

What type of IT-environment errors are we talking about?

I would assume some to be server downage, but most errors being user profile related.

If the server or user is inaccessible, then this would need to be solved from the Robot-allocation side or IT needs to be on top of the issues more effectively (which they never are!). Orchestrator is supposed to only allocate on accessible robots, but this isn’t always reliable since a user profile could still show ‘connected’ but not really working. - Technically, you could build some monitor job that runs frequently to check the accessibility or user profile corruption and mitigate these types of issues. :man_shrugging:

The other types of issues which are more common are the user-profile related ones. This could be like Internet Options being reset that turns off popups / changes security settings cause websites to stop working, Chrome extension is not working, application versions different or not configured, and other things. These types of errors allow the robot to function but cause it to fail on one user profile but work on another.

I do believe that most of the Framework components should be deployed as a Library, anyway. However, I’m not sure that applying this solution (ie, to fix the user profile settings) as part of the Framework Library, which requires mass updates, is really necessary. This is because you can run a separate job that fixes these things, and you can optimize the Framework to effectively use multi-threading to continually start jobs on working robots.

So, the question is, is it better to schedule a separate job that checks and fixes user-setting issues? If you include this type of thing as part of each job, it could add several minutes of process time per day and also require mass updates when changes are needed.

I also mentioned ‘multi-threading’. I believe this is a very good way to get around user-profile setting issues, because when the job fails a transaction, the Framework will recognize that it needs to trigger the job again to equal the specified number of robots that it’s set to run on. I have had lot of success with this.

For the effective use of multi-threading, some optimizations will be needed, even still with my own projects. In the end, the job would be able to know how many robots it wants to run transactions with (a dynamic number, keeping a certain number of robots available for other critical jobs) and start the concurrent job if transactions are available.

So maybe if this is combined with notifications when a setting issue is detected (a robot fails consecutive times), resolving these things is more efficient.

Sorry if these ideas are a bit unorganized :sweat_smile:

Thanks
Clayton

2 Likes

Hey Clayton,

thanks for the response. I must have read your answer ten times by now, but I’m still struggling to understand the whole multi-threading concept.

I was not talking about any specific kind of error, but some can surely be categorized as server issues. What I get from your answer, is that you would rather recommend building a separate job to fix user profile settings etc. and then continue with the original job?

Does the multi-threading mean, that these two jobs would run in parallel on the same user and machine?

1 Like

Where it runs transactions on multiple different users and machines at the same time. So, if one user / machine combination is broken, it still runs cause other user / machine combinations would be working and still execute the transactions.

To be effective, though, each running job would need to check the number of running jobs to ensure it starts a new job if one fails. It’s also possible newer versions of Orchestrator has autorun for Queues, which is not something I have explored if it does.

That is my initial thinking because if every job that runs does some type of setting validation, that could add considerable time away from business processes throughout the day. Server configuration probably only needs to be checked once daily.

1 Like

Hey @code_monkey . I see that you were successful with this, but for some reason I cannot seem to get mine to work. I am trying to use try/catch within a for/each loop. You can see my issue here, and if you have any ideas, I would appreciate your advice!