Try catch and re-throw exception

Question

I saw some code the other day in one of our projects that uses a try catch and re-throws the caught exception like this:

try
{
    exceptionProneCode();
}
catch(Exception ex)
{
    throw ex;
}

Nothing else was done with the exception in the catch block so I'm not even sure why it's re-thrown. I can't see any benefit to actually throwing the same exception again and doing nothing with the exception.

If you re-throw an exception that's caught in the catch block, how does C# handle this? Does it get stuck in an infinite throw/catch loop? Or does it eventually leave the try catch?

Any chance there was a `finally` with the `catch`? Maybe someone accidentally included the `catch` out of habit? (one can hope) One possible benefit would be step-through-debugging could break-point the catch (not advocating! I'd probably wrap with extra data and re-throw the new chain.) — , Sep 27 '13 at 18:29
No, there was no `finally` included with the `catch`. I just didn't fully understand why one would re-throw the caught exception. I'm getting a better idea about that now. — Cameron Tinker, Sep 27 '13 at 18:32
My suspicion is that this was done so that a breakpoint could be put in to see the exception. That is a possible advantage, whereas losing your stack trace isn't usually an advantage. As others have noted, throw should have been used instead of throw ex (common mistake). — sammy_winter, Sep 27 '13 at 19:07

Alireza · Accepted Answer · 2013-09-27T18:34:02.123

11

Consider these two models:

1- By re-throwing ex:

catch(Exception ex)
{
    throw ex;
}

you loose StackTrace. If the exception is logged somewhere the StackTrace containing immediate frames of the call stack (history of method calls) is lost.

2- In contrast by throw:

catch(Exception ex)
{
    // do something here
    throw;
}

you maintain StackTrace. You can do additional processing and then re-throw the exception without loosing the trace string.

edited Sep 27 '13 at 18:34

answered Sep 27 '13 at 18:24

Alireza

10,237
6
43
59

1

While all of this is true and helpful, I'm not sure how this addresses the question. – vcsjones Sep 27 '13 at 18:28
@vcsjones Nobody can say for 100% sure what a developer really wanted to do by looking at his code. Here, I tried to explain one of the most probable reason he coded like that. It's up to the OP to infer :) – Alireza Sep 27 '13 at 18:31
I'm in the process of trying to track down a bug in one of our projects and was wanting to understand how the exception travels up the call stack. This is very helpful! Thanks! – Cameron Tinker Sep 27 '13 at 18:42
@CameronTinker Glad to be helpful! – Alireza Sep 27 '13 at 18:44
3

A common situation is if you are going to put a wrapper around the exception and throw the original exception as a InnerException `throw new MyCustomException("Some useful information", ex);` – Scott Chamberlain Sep 27 '13 at 18:45

score 4 · Answer 2 · answered Sep 27 '13 at 18:25

It continues to throw the exception up the calls stack. One thing that this piece of code does that is different from if you didn't catch the exception, it will reset the exception location (call stacks, line #, etc) to where you re-threw the exception, so you won't have the location where the original exception was thrown.

If you're not going to actually do something in the catch block I would recommend not catching, or at the very least rethrowing with just a throw instead of throw ex.

score 2 · Answer 3 · answered Sep 27 '13 at 18:24

2

It throws the exception to the caller. But it handles it here so it doesn't throw an unhandled exception. However, honestly, I don't see the benefit of this. Just let it throw the exception. Why? Because an exception is only unhandled if the entire call stack above it doesn't have a try ... catch. This isn't doing anything useful.

answered Sep 27 '13 at 18:24

Mike Perrenoud

66,820
29
157
232

1

If the caller fails to handle the exception it will still be an unhandled exception. – Sep 27 '13 at 18:24

score 1 · Answer 4 · answered Sep 27 '13 at 18:31

Does it get stuck in an infinite throw/catch loop? Or does it eventually leave the try catch?

No. Yes.

The code provides no benefit and does harm to debugging as noted by everyone else.

A good catch block will catch a specific expected issue and log & continue (the problem doesn't indicate the applications state is corrupt), log and halt (because the application is now in an unknown state and continuing could wreck more harm), do something else (e.g. fall back to an equivalent technology/algorithm), wait and try again.

The default is that something is unexpected, should be logged and the application should be stopped-- either abandoning the page or if a winforms app, revert back to a known state if possible.

Try catch and re-throw exception

4 Answers4