Is there a benefit to JUST a “throw” in a catch?

Question

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.

Private sub foo()
    try
        'Do something'
    catch
        throw 'And nothing else!'
    End Try
End Sub

My thought was to not even bother (assuming you don't need to do anything at this point) - the exception would bubble to the next exception handler in a parent member.

The only argument that sounded plausible was that sometimes exceptions weren't caught and your code stopped (in debug mode) with the current line highlighted in green...and that this may be something to do with multiple threads? Best practice does state "an exception handler for each thread" but mostly we work single-threaded.

The good thing may be it could be useful in debug mode to not suddenly pop out to a parent member (yes, Joel!) - you'd move to the "throw" statement and be able to examine your locals. But then your code would be "littered with try/catch/throws" (to quote another thread here)?

And what sort of overhead would be involved in adding try/catch/throws everywhere if no exception occurs (i.e. should you avoid try/catches in tight loops)?

Answer 1

This can also be useful if you need to inspect something about the exception, and do something for one circumstance or throw it for other circumstances. For instance, if you need to inspect the error number in a SQLException. You can perform a certain action if the error number is one you're prepared to handle. For others you can simply "throw" it so the stack trace is preserved, as mentioned above.

Answer 2

Since there is zero error handling, this catch is useless. If there was logging or some cleanup done sure, but in this situation I'd get rid of the try/catch.

Answer 3

Doing it always by default looks like bad design. But there might be reasons for catching and throwing, for example it you want to throw a different exception.

Answer 4

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.

Answer 5

Microsoft recommends not to catch an exception when the only thing you do is to rethrow it immediately (i dont remember the source for now). Your code should only catch exceptions that you want to handle for clean up things or similar actions.

So generally its not a good practice to catch and rethrow an exception.

Reasons for catching and replacing it with another exception might be

• Logging
• Hiding sensitive information from the caller (Stacktrace, exception details)

And for debugging you might want to change your "Break when an exception is:"-Handler (Press Ctrl+Alt+e) the value "thrown" on selected CLR Exceptions.

You might want to take a look at the entlib exception handler block (EHB), with which you can establish a pattern on how to deal with exceptions in your code.

Regarding your question on performance i think its not a propblem to have many try/catch blocks in your code but you will get performance hits when your code raises and catches many exceptions.