QUESTION- Recommendations or Approaches to layered Try/Catch (T/C) blocks

Help Studio
, ,
1

Looking for recommendations on how to appropriately handle multiple layered T?C blocks.

We are using the Uipath Computer Vision service somewhat heavily for a rather OLD piece of software. The reason being the display framework this software uses for a table-like structure in a GUI client is so old that the rows/columns are not identifiable and UiPath sees it as an image. CV works great 99.9% of the time until we get the dreaded “Response from server is not valid” error.

We have hit this on an embedded CV Extract Table activity within the CV Screen Scope. I have the CV Extract Table wrapped in a looped T/C (using a Do While). Recently, this error hit the CV Screen Scope activity itself.

So now I have to wrapped that as well. This is all being run within a REF based workflow. So this will entail three layers of T/C.

Just looking to see if anyone has a basic design pattern for handling this - knowing this isn’t a specifically hard question but it isn’t simply either.

TIA.

2

Hi Sean,

It depends on what you want to do/ how you want to manage the error. Is this error blocking the whole process ? Or the robot can continue its work even if this throws an error? Do you want a specific action to happen just for this error ?

If no, then you can remove your two T&C and let the REFramework’s one handle the task. You can manage what happens for all errors in the SetTransactionStatus.xaml (for example, you want an email to be sent with the exception message, etc). With this, the robot will throw an application exception error every time it encounters your described error.

If you want a specific action to happen for your described error (throw a business exception instead of an app one, close the window not kill the processes etc…) then let your T&C.

My advice is to think about the error handling. The REFramework does its job perfectly, so if you are just afraid everything crashes, you should not :slight_smile:

Best regards,

3

Hi @riverrat437

Let’s go one by one so that it would be easy to attain the final design
—first let’s take the one that you have used now
Try catch block generally helps in two ways
First if you want to know why an activity failed it can be logged in with a log message by specifying it in a CATCH Block because once the error occurred it will go to Catch block

Second more than just knowing reason if you want to rerun the same set of activities or to run different set of alternative activities then it can be mentioned in CATCH block

So now in your scenario is there any need of rerunning the same activity or another alternative activity or just to log the reason and continue with next transaction then it’s absolutely fine to continue with the same way of approach you have now

-second which is something that is not being used now in your code, using RETRY SCOPE
This will retry same set of activity again and again to the number of times we mention and it can be included in your current one by just placing the activity in this sequence

-Try block
-Retry scope

  • your activity
    Leave the condition empty and mention the number of retries

This is another way but it’s again based on the process you have and I hope these ways can really help you handling exceptions

Cheers @riverrat437

4

Hello and thank you for the reply.

We do use the REFramework and its included TC works just fine. However, our challenge is the CV cloud service can have hiccups at times at least from my customer’s location. These CV hiccups (or something in the path to cloud-based CV is causing this) is very transit and rare but job terminations for this hiccups are very problematic as these jobs run when there is no one available at that time to manually correct/restart/whatever these jobs.

The issue with using JUST the REF TC you only have a single unhappy path up at the very top of your workflow chain.

We have a situation where we use cloud-based CV “a lot” because of how old a piece of software is. As previously mentioned, CV works great 99.9% of the time. Then the 0.1% toll tax come into play and we get a hiccup. Any number of issues outside of UiPath could be contributing to this which the workflow has no control over.

What I got working yesterday and a layout of how this TC blocking works is the following:

  • (1 layer) REF TC is there for final Exception push to terminate the job as a LAST resort - for these CV hiccup errors.

  • (2nd layer) Workflow that uses CV has a Do-While looped TC block around the “CV Screen Scope” Activity. If this CV activity hits the dreaded “Response from server is not valid” (the hiccup), it will sleep 5 seconds and try it again. It will do this up to 5 times. After 5 times, it throws a exception which the (1st layer) REF TC captures and terminates the job.
    *** Assuming the CV Screen Scope works (like it should OR after a failure up to 5 times), it simply continues with the normal processing.
    *** If the CV Screen Scope throws an Exception outside of “Response from server is not valid”, it throws it so the (1st layer) REF TC terminates the job.
    *** If this gets the Exception thrown by 3rd Layer below, it Rethrows that.

  • (3rd layer) Inside the CV Screen Scope is a “CV Extract Table”. This can also get the “Response from server is not valid” error at any time. This is also wrapped in its own Do-While TC. This does the same thing as the 2nd layer TC block. It will attempt the CV Extract Table up to 5 times for that specific error. ANY other error will force the exception to bubble to the 1st layer REF TC for job termination (through the 2nd layer TC).
    *** Assuming the CV Extract Table works (like it should OR after any failure up to 5), it simply continues with the normal processing.
    *** If the CV Extract Table throws an Exception outside of “Response from server is not valid”, it throws it so the 2nd Layer TC handles it.

The point of this heavy TC logic is to continue the job as much as possible.