In the Catch block, the System.Exception should be catched by default and a Log Message activity should be used here automatically. This can be considered a template
I’m not sure if I agree with that - in general a catch-all should only be used in limited scenarios, where the developer knows the implications of doing it, as continuing may lead to corrupt state or data.
Putting that as the default may suggest to newer/less technical users that this kind of a design is the norm, where in most cases it shouldn’t be.
Please also bear in mind that since rearranging Catch clauses is currently not possible directly within UiStudio, it may lead to unexpected behaviours for newer users, while for people that know what they’re doing will lead to extra work to delete the defaults to be able to add catches in correct order.
It doesn’t matter in which order you add catches in UiPath. The most specific one will be triggered and most of the times you also add the System.Exception catch and you add a Log Message activity
Allowing unreachable exception
That’s a new one… Didn’t even think that something that normally is a compiler error (CS0160) would work like this. Does MSDN documentation on TryCatch contradicts their implementation? Or I wasn’t able to find the newest one…
Either way you’re right - TryCatch implementation does search for the most relevant type through an internal method call. Strange… but useful.
In that case I stand corrected and the default you’ve suggested seems reasonable.
I’m happy to be wrong
This is a great idea
Seriously though we use Try Catches all the time within our workflows and adding in an automatic log for any Exception that has been created would save a fair bit of work. It’s easy to forget and errors can easily get hidden when you have large processes.
Why not use a library .xaml?