如果在使用块中进行了返回调用，那么幕后操作的顺序是什么？

Question

Does the end of the using block get hit if a return is called inside of it? For example,

using( var ur = new UnmanagedResource() )
{
  if( SomeCondition == true ){
   return SomeReturnValue;
  }
}

When SomeCondition is true , will the UnmanagedResource be disposed from the end of the using block before the return is called? What is the order of operations behind the scenes that would take place in this scenario?

Answer 1

I have no idea what "before the return is called" means. "Called" is something that happens to functions, and there's no function known as "the return". When the return statement appears in your program, it causes several things to happen:

1. The return value expression is evaluated and stored.
2. Execution returns to the caller.

Unwinding using and finally blocks happens in between steps 1 and 2.

Answer 2

finally block runs before the control leaves the using block.

So really this is the code that actually gets compiled:

var ur = new UnmanagedResource()

try
{        
    if( SomeCondition == true ){
        return SomeReturnValue;
    }
}
finally
{
   ur.Dispose();
}

Answer 3

It will be disposed when you leave to block. If you dont leave the block at the } but at the return it will be disposed there (so my teacher told me :))

Answer 4

Does the end of the using block get hit if a return is called inside of it?

Yes.

using is translated into the try/finally sequence, where finally is guaranteed to be executed (in normal circumstances) either there is exception or not.

Answer 5

The object is disposed prior to the control flow returning to the caller of the method.

This is detailed in the C# language specification, section 8.9:

Execution of jump statements is complicated by the presence of intervening try statements. In the absence of such try statements, a jump statement unconditionally transfers control from the jump statement to its target. In the presence of such intervening try statements, execution is more complex. If the jump statement exits one or more try blocks with associated finally blocks, control is initially transferred to the finally block of the innermost try statement. When and if control reaches the end point of a finally block, control is transferred to the finally block of the next enclosing try statement. This process is repeated until the finally blocks of all intervening try statements have been executed.

...

finally blocks associated with two try statements are executed before control is transferred to the target of the jump statement.

Since a using statement is turned into a try/finally (detailed in 8.13), this means the Dispose call is guaranteed to occur "prior to the return" (rather, prior to control flow jumping to the caller of this method), as return is a "jump statement".

Answer 6

The order of operations you seem to be looking for is:

1. The return statement is reached.
2. The value to be returned is calculated and stored on the stack to be used when control pops back up from the function.
3. The control prepares to leave the using block, thereby executing the implicit finally within the using block which calls the relevant .Dispose() .
4. Control leaves the function and the calling function accesses the value on the stack.

Note that sometimes this presents an unexpected result. For example, suppose you do something like this:

using (var db = new SomeLinqDataContext())
    return db.Somethings;

In this case, the return value isn't an actual value but a delayed-execution "pointer" of some sort to the resource (I'm sure there's official terminology with which I'm unfamiliar). But that resource is being disposed before that execution takes place. (It's disposed after return is reached but before the calling function evaluates the returned result.) So you end up with an error attempting to access a disposed resource.

Answer 7

From Brendan Enrick's blog:-

While writing some code earlier today I needed to return from within a using statement. Doing these sorts of things always makes me appreciate the using statement and how wonderful it really is, so I decided to write about it here. As many of you know the using statement in C# is a good tool for managing types which will be accessing unmanaged resources. Some examples of these are SqlConnections, FileReaders, and plenty of other similar types. The key to these is that they all implement the IDisposable interface. This means that they all need to be cleaned up carefully after using them.

The using statement is great because it guarantees that the declared object is disposed no matter how the execution completes. Whether you reach the end curly brace marking the end of the using statement, throw and exception, or return from a function, the using statement will call the dispose method and clean up the object.

This was important in my code because I was able to return directly from within the using statement without worrying about whether or not eh dispose method will fire. Whenever I use an object which accesses unmanaged resources I always always always put it in a using statement.

It is very important to use a using statement, because it will give you this guarantee that the object will be disposed of correctly. The object's scope will be for the extent of the using statement, and during the scope of the object it will be read-only if defined in the using statement. This is also very nice, because it will prevent this important object which manages the unmanaged from being modified or reassigned.

This is safe to do, because of how great the using statement is. No matter which return we hit we know the XmlReader will be disposed of correctly.

using (XmlReader reader = XmlReader.Create(xmlPath))
{
    // ... Do some work...
    if (someCase)
        return 0;
    // ... Do some work...
    if (someOtherCase)
        return 1;
}
return -1;

One more of his blogs illustrates a live example