2

There's a good question Catch block is not being evaluated when exceptions are thrown from finallys that is discussing some of the sometimes unexpected results of throwing an exception in a finally block.

I can't think of any good reason why you would want to throw an exception in a finally block. If there was a previous exception, it would always be lost. I've always seen finally used to clean up in ways that should never throw an exception.

Can anyone explain when it would be appropriate to throw an exception in a finally block?

Community
  • 1
  • 1
Samuel Neff
  • 73,278
  • 17
  • 138
  • 182
  • Exception thrown inside finally will be caught by the respective catch block in caller place. But as Peru says, why should you even think of messing up things when its given to be more safer and cleaner? Finally is to clean up the mess n not to make it more. – Zenwalker Aug 28 '12 at 05:00
  • 1
    The thread you mentioned starts from a point that an exception is thrown by the clean up code...not by means of `throw` and contrary to the expectations of the developer....so is there a question '*whether to throw exception from a finally block and when*' at all? I guess it isn't... – horgh Aug 28 '12 at 05:05
  • In that original post http://stackoverflow.com/questions/12150994/catch-block-is-not-being-evaluated-when-exceptions-are-thrown-from-finallys I gave an answer, saying to wrap the content of the `finally` block into try..catch to avoid any possible exception in the finally block...And I still think, it should be done just like that, if one has any warnings that the finally block could throw an exception – horgh Aug 28 '12 at 05:07
  • 1
    If only the WCF folks knew that is isn't a great ideato throw from `finally`, maybe they wouldn't have added that broken `.Dispose()` ! – Marc Gravell Aug 28 '12 at 05:49

3 Answers3

1

try catch finally is pretty important construct. You can be sure that even if an exception is thrown, the code in finally block will be executed. It's very important in handling external resources to release them. Garbage collection won't do that for you. In finally part you shouldn't have return statements or throw exceptions. It's possible to do that, but it's a bad practice and can lead to unpredictable results.

Peru
  • 2,871
  • 5
  • 37
  • 66
1

When you have a Exception thrown in finally it propagates up and most important stops at the point where the Exception is thrown, so the remainder of the finally would not be executed. Also if an exception has occurred in the try block it would have vanished and as the current one would be thrown from the finally block.

I am not able to think of any scenario as in where you would have a finally throwing up the Exception and then handling it at the caller level for a specific reason (there could be other ways of managing such logic), so you can at the caller level process further based on the Exception thrown.

All i can say is all the eyes that would read and try to follow the code later will have a healthy surprise.

V4Vendetta
  • 37,194
  • 9
  • 78
  • 82
1

It is fine, well supported by .NET. The problem is catching the exception, that's a very poor practice. The odds that you'll properly restore program state are very low.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Are you saying it's fine to throw the exception from finally but not to catch an exception thrown by a finally block? I don't follow the reasoning. Doesn't this always result in the application shutting down? – Samuel Neff Aug 28 '12 at 20:22
  • Of course. Which is what you want. You cannot handle an exception if you cannot restore the state of the program back to a state it had before the code started running that threw the exception. Be sure to avoid assuming that exceptions should always be caught. – Hans Passant Aug 28 '12 at 20:33