Been having a \"heated debate\" with a colleague about his practice of wrapping most of his functions in a try/catch but the catch has JUST a \"throw\" in it e.g.
In practice, my thought is, if you don't intend to handle the error, don't catch it.
The reason you have a lone throw inside a catch rather than throwing a new exception is because this causes the original stack trace/exception data to be preserved. And one reason you might do this is because you can now set a break-point there for debugging.
One effect of using a catch and immediate rethrow is that any inner "Finally" blocks will run before the "Catch" occurs (which will in turn be before the exception propagates). This is relevant in two scenarios:
An additional caveat with catch-and-immediate-rethrow: for some reason, a catch and immediate rethrow will trash the stack trace's line number for the function call that caused the exception. I don't know why the current function's entry in the stack trace can't be left alone in that case, but it isn't. If one isn't using a .pdb file to get line-number information, this isn't an issue, but if one wants to use such information, it can be annoying.
Generally, the effects mentioned above aren't desirable, but there are occasions when one or both of the first two effects they may be useful, and the third effect tolerable. In those cases, a catch with immediate rethrow may be appropriate, though the reason for it should be documented.
I would only ever do this while debugging an issue - and I'd remove the code again before checking in. It can occasionally be handy to put a breakpoint in to stop at a particular stack level if an exception is thrown. Beyond that though - no.
If you catch an exception and replace it with another exception, you should typically wrap the original exception in the new one. This is usually done by passing the old exception into the new one's constructor. That way you can dig in as much as necessary to figure out what happened. The main case when you wouldn't is when you need to hide data for security reasons. In these cases, you should try to log the exception data before you clear it out.
The rationale I have seen for wrapping exceptions with new ones, rather than just letting them bubble up the stack, is that exceptions should be at the same symantic level as the methods they are coming from. If I call AuthenticateUser, I don't want to see an SQL exception. Instead, I should see some exception whose name tells me the authentication task could not be completed. If I dig into this exception's inner exceptions, I could then find the SQL exception. Personally, I am still weighing the pros and cons of doing this.