Agreed. It all comes down to properly analysing the design - as long as the taken actions are the same, it can be handled by one TryCatch. There is not much point in catching an exception if all you do is rethrowing it higher without adding anything to it or handling it.
It might be that general perception of exceptions and errors is still that they’re bad and letting them bubble up is even worse (hint: it’s not, at least not in and of itself). There are even situations where you WANT the robot to crash/fail gracefully (think network outage - I still sometimes get a confused look after saying “if this happens, robot will do this, this and then crash”).
I’ve also seen situations where there was so much try catching that the root cause of the issue was a pain to find. It’s even more important with workflows, as heavy nesting of activities makes it really, really hard to read ( and with TC, you can see either Try or Catch or Finally which makes it even worse).
I’d say that TryCatch is “by default” recommended on:
- Process step boundaries
- Activities that are known to throw errors even though nothing is wrong (think OCR -> “Scrape returned empty text”)
Everything else is a case-by-case, usually because there is an identified (and that’s the key) need to handle this particular activity failing and do something with it in this particular point in the process. And that’s actually not that often as one might think.
It might also be that the robots are still developed in a waterfall model, where you try to anticipate everything that could go wrong within the processing and design to that. I’m finding iteration based design much more efficient, especially since it usually doesn’t take long to do each part and run it through for testing.
It would be even better if there would be a Compensate part in the Retry (as in actions that will revert the state of the application so that another try is possible).
A thing that gets much less spotlight is that with each retry, dev is extending the time boundaries one transaction can take. That’s one thing that actually makes me still use standard looping sometimes instead of Retry - I want to clearly know which try works.
A real life example: a form often fails to open in the target app - we added retrying (3 tries). After analysing the work afterwards, it has been seen that the last retry never worked (literal never), but was still consuming time. With using Retry, this decision would not be possible (or at least much harder to find) and we would still be wasting time on something that doesn’t give any benefit.