Is this a case for the Global Exception Handler?

Help
1

Hi guys,

Looking for some advice regarding exception handling. Not a total rookie but not really experienced yet either :slight_smile: I’ve built a couple of smaller processes before that seem to do the job. This time however, I’m a bit lost. The latest process I built is by far the largest so far with more than 100 activities (clicks, type ins, if-statements and whatnot). It starts with an Excel-sheet with around 1200 rows that should be entered into this browser based application. During debugging I smoked out a whole bunch of exceptions with various TryCatch and Find Element-activites and playing around with Delay Before/After and WaitForReady. I did this to a point where the process finally seemed stable and robust enough to start working the production data.

However, working the production data is generating new exceptions all the time that seem related to the environment (I verified it’s not due to errors in input data). It processes around 30-60 lines from the Excel and then some new random error pops up. I’ve reached the point where it just feels impossible to handle all of those through tweaking the code around the specific activity. (I’ve also considered maybe this application is just not suited for UI-automation… there’s a lot of pop-ups and windows inside windows inside windows… but I haven’t given up completely yet).

So to my question: what would be the recommeded way to handle a situation like this where the environment plays tricks on the automation. I stumbled upon the Global Exception Handler and also read about the REFramework (though that seems tricky to me). I feel most of the errors are timing based (it seems to work better during night when the load is smaller.)

Any advice from people with similar experience highly appreciated.

Thanks,
Andreas

2

Hi @athuroe

Without knowing the specifics of your app/automation flow, it is hard to advise on a concrete solution.

I would definitely suggest using the ReFramework to handle your process. Its sole purpose is to allow you to retry failed transactions and keep track of the ones that were completed.
S
ometimes it is easier to reset the state of the app upon exception and simply retry the transaction that failed rather than trying to move it forward with exception handling on every step.
(I’m aware though that my view might very well be be verified by other users with more development experience tough :slight_smile: )

1 Like