First of all, a disclaimer: I have experience in other languages, but am still learning the subtleties of C#
On to the problem... I am looking at some code, which u
Try / Catch / Throw are slow - a better implementation would be to check the value before catching it, but if you absolutly can't continue, you are better off throwing and catching only when it counts. Checking and logging is more efficient otherwise.
If every layer of the stack just rethrows the same type with the same information, adding nothing new, then it's completely absurd.
If it was happening at the boundary between independently developed libraries, it's understandable. Sometimes a library author wants to control what exceptions escape from their library, so that they can change their implementation later without having to figure out how to simulate the previous version's exception-throwing behaviour.
It's generally a bad idea to catch and re-throw under any circumstances without a very good reason. This is because as soon as a catch block is found, all the finally blocks between the throw and the catch are executed. This should only happen if the exception can be recovered from. It's okay in this case because a specific type is being caught, so the author of the code (hopefully) knows that they can safely undo any of their own internal state changes in response to that specific exception type.
So those try/catch blocks potentially have a cost at design time - they make the program messier. But at runtime they will only impose a significant cost when the exception is thrown, because the transmission of the exception up the stack has been made more complicated.