Most of what you’re asking here is covered in the academy lesson 12 (I don’t think Throw is though). At least to a level where you should be able to understand how to use it in most cases, not necessarily how it works.
There’s IMHO 2 reasons why for these parts UiPath doesn’t go too deep, which are themselves a Catch-22:
- It’s already documented for .Net and Workflow Foundation by Microsoft, so it’s redundant. But if you’re not a programmer, you might have a hard time reading into it or even finding it.
- If they do document it, it’s redundant and either the documentation will be worthless for the most part (don’t go deep) or it will repeat what’s already on MSDN.
There’s no easy solution to that, as the audience for UiPath is very broad - from very technical to business people. You can’t satisfy all.
Some small corrections though:
Exception is created by the code that was trying to execute and failed. The “exception” object in the Catch clause is an object where exception data is stored once it bubbles up to that point. Btw - you can change the name as you please.
Not exactly. Rethrow let’s the exception pass further up - it’s still exactly the same exception (this is a key difference between using Rethrow and Throw(oldException) ).
You probably know that, but for potential other readers - object created needs to be of type Exception or any of the derived types (ArgumentException, BusinessRuleException).
And that’s the thing - you can dive as deep as you want with this, question is how for is it actually worth it, since it’s already there by other parties (MSDN and programmer sites). It’s an unfortunate reality for non-programmers - sooner or later you will need to start using programming knowledge (you already are if you’re using Uipath, even if you don’t realise it) or you will hit a usefulness ceiling.