5

I'm trying to wrap my head around this. According to this page on Using statements:

The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object. You can achieve the same result by putting the object inside a try block and then calling Dispose in a finally block; in fact, this is how the using statement is translated by the compiler.

But on this page about Try-Finally blocks it states:

Within a handled exception, the associated finally block is guaranteed to be run. However, if the exception is unhandled, execution of the finally block is dependent on how the exception unwind operation is triggered.

So how can a Using statement be guaranteed to call the Dispose method in the event of an exception if it translates to a Try-Finally that is not guaranteed to call the finally statement?

TrueEddie
  • 2,183
  • 2
  • 26
  • 36
  • Not an answer because I don't know that I'm right, but I believe that it's saying that if there's an unhandled exception within the catch statement, then finally will not get called. But with the catch statement that's autocreated by using, there's nothing but a call to dispose(). – GendoIkari Feb 02 '16 at 19:23
  • @GendoIkari: No, it's not related to where the exception is being thrown from, but whether if it's eventually caught or not. An exception that is eventually caught (handled) will invoke the finally block, always (even if another exception is thrown from a catch). An unhandled exception, a little surprisingly, may or may not invoke the finally. – Cameron Feb 02 '16 at 19:25
  • @Cameron: Thanks. I guess I was assuming that if you have a finally, then you are also handling exceptions. But I suppose it is possible to have a catch that only handles specific exceptions; or a try/finally without a catch. – GendoIkari Feb 02 '16 at 19:27
  • @code4life, no I'm not a troll. In doing my job I was writing code and wanted a better understanding of how the using statement works. I found it interesting that it converts to a try-finally. But this confused me for the reasons I mentioned above. Also why would I do so much research just to troll? – TrueEddie Feb 02 '16 at 20:11
  • @TrueEddie: sorry about that, deleted my comments. That being said, I got the feeling that you haven't really tried to even test your questions with a simple program. If I'm wrong, I apologize. – code4life Feb 02 '16 at 20:15

3 Answers3

10

It really does behave like a try/finally - so if the application terminates, the resource may not be disposed... and that's usually okay, because normally disposal is for releasing resources held by the process... and the OS will tidy those up anyway on process death. (That's not to say the Dispose method won't be called... it's just the same as with a normal try/finally.)

Obviously if you've got a "lock file" on the file system or something like that, that would be a problem - but you'd have the same problem in the face of a power cut etc.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    I think maybe the OP thought "unhandled" meant "uncaught in the immediate try/finally block," not "unhandled by the application as a whole." – adv12 Feb 02 '16 at 19:26
  • So you're saying that a Using statement can't really guarantee that Dispose will be called, right? – TrueEddie Feb 02 '16 at 20:24
  • @TrueEddie: Indeed - it can only guarantee it to the same extent as normal try/finally. – Jon Skeet Feb 02 '16 at 20:54
5

There are exceptions from which a program can't recover, in that case finally block will not execute. For example Stack overflow exception or Out of memory exception.

Habib
  • 219,104
  • 29
  • 407
  • 436
0

If the exception unwind only ends with an unhandled exception that crashes the program then finally blocks do not run as execution ceases.

tl;dr Finally blocks are only run on success or on handled exception.

Matt Clark
  • 1,171
  • 6
  • 12