Yes, Dispose
will be called. It's called as soon as the execution leaves the scope of the using
block, regardless of what means it took to leave the block, be it the end of execution of the block, a return
statement, or an exception.
As @Noldorin correctly points out, using a using
block in code gets compiled into try
/finally
, with Dispose
being called in the finally
block. For example the following code:
using(MemoryStream ms = new MemoryStream())
{
//code
return 0;
}
effectively becomes:
MemoryStream ms = new MemoryStream();
try
{
// code
return 0;
}
finally
{
ms.Dispose();
}
So, because finally
is guaranteed to execute after the try
block has finished execution, regardless of its execution path, Dispose
is guaranteed to be called, no matter what.
For more information, see this MSDN article.
Addendum:
Just a little caveat to add: because Dispose
is guaranteed to be called, it's almost always a good idea to ensure that Dispose
never throws an exception when you implement IDisposable
. Unfortunately, there are some classes in the core library that do throw in certain circumstances when Dispose
is called -- I'm looking at you, WCF Service Reference / Client Proxy! -- and when that happens it can be very difficult to track down the original exception if Dispose
was called during an exception stack unwind, since the original exception gets swallowed in favor of the new exception generated by the Dispose
call. It can be maddeningly frustrating. Or is that frustratingly maddening? One of the two. Maybe both.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…