‘using’ IDisposable objects

re: ‘using’ IDisposable objects

Alex Skorkin — Tue, 11 Jan 2011 12:32:27 GMT

Peter Gfader,

CodeRush Pro has "code issues" feature that highlights undisposed locals and has a fix to automatically apply a using statement on code in question.

re: ‘using’ IDisposable objects

Peter Gfader — Thu, 06 Jan 2011 02:32:47 GMT

Is there a tool that can warn us when we new up instances of IDispsable without using statement?

E.g. Reshaper, JustCode, CodeRush, Code Analysis...

It would be nice to tell us if we create of a "Type" that implements IDisposable and that is not used with a using statement...

re: ‘using’ IDisposable objects

Richard — Tue, 04 Jan 2011 19:21:30 GMT

It's not just Mono or third-party libraries which have problems implementing IDisposable - try disposing of a ReaderWriteLockSlim twice and see what happens.

connect.microsoft.com/.../readerwriterlockslim-does-not-implement-idisposable-properly

Cygnus: If you want a language with determinate destructors like C++/CLI, then why don't you try C++/CLI? I hear it can handle this much better. :o)

re: ‘using’ IDisposable objects

Cygnus — Mon, 03 Jan 2011 21:27:17 GMT

This is why C# is still a toy - its stubborn refusal to have determinate destructors. C++/CLI can handle this much better. It should not be necessary to know if native resources need to be released. Resources should be released when no longer necessary - period.

re: ‘using’ IDisposable objects

StarTrekRedneck — Sat, 01 Jan 2011 07:01:54 GMT

Regarding the VB translation, for brevity we can combine them into one Using statement:

Using stream As Stream = storageContainer.CreateFile("MyFile.txt"),

writer As New StreamWriter(stream)

writer.Write("Stuff")

End Using

re: ‘using’ IDisposable objects

Stark — Fri, 31 Dec 2010 12:36:26 GMT

I agree that you should at least be careful about bad implementations and test it accordingly, then you could proceed to either fix the 'bug' if you can or go for the try-finally alternative. You can never be sure unless it's a .NET type that the 2nd object's Dispose will take care of the 1st one.

Also, just in case, especially if you can't use the using because you need to return the object, you could implement the special 'finalize' method so that it calls the Dispose if the object is not disposed already.

In the end, nothing can replace a good testing strategy, though.

re: ‘using’ IDisposable objects

Werner van Deventer — Wed, 29 Dec 2010 20:09:44 GMT

There is actually a problem with this and all the posts making use of nested 'using' statements. If you use static code analysis you will be warned of nesting a 'using' statement that uses the object created in the previous 'using'. CA2202: msdn.microsoft.com/.../ms182334.aspx

The issue is because the second object usually takes ownership of the first. When disposing the second/nested object (by going out of scope) the first object will get it's dispose method called as well. When the first object goes out of scope the dispose method will be called again.

This is not usually a problem when coding with built-in .NET types but generally isn't good for business, as long as MS keeps to their own standard... from the rule page itself "A correctly implemented Dispose method can be called multiple times without throwing an exception. However, this is not guaranteed and to avoid generating a System.ObjectDisposedException you should not call Dispose more than one time on an object."

I've been bitten by this issue in Mono and it will probably happen again when using third party libraries that don't implement IDisposable correctly. Better safe than sorry!

re: ‘using’ IDisposable objects

Greg — Wed, 29 Dec 2010 19:53:12 GMT

Thank you, this was very helpful. I am now updating my current project to make use of this, but since I am doing this in VB, I thought I would add a translation.

Using Stream As Stream = storageContainer.CreateFile("MyFile.txt")

Using writer As New StreamWriter(Stream)

writer.Write("Stuff")

End Using

re: ‘using’ IDisposable objects

Siderite — Wed, 29 Dec 2010 17:10:53 GMT

I also love the pattern when you implement IDisposable on a token object so that the Dispose method would cancel an action or unregister an event. Something like var token=BindToEvent() and then, when you want to stop handling the event, token.Dispose().

re: ‘using’ IDisposable objects

Parrotlover77 — Wed, 29 Dec 2010 14:35:16 GMT

MikeBMcL - I agree with the dissenters on that MSDN page and the author of this article: nested 'usings' encourages good coding practice by keeping it simple, readable, and consistent. CA2202 makes no sense. If a dispose method is incorrectly implemented and multiple disposes causes a problem, then that's a bug in the library and the library should be fixed.

As you said, it's very easy to test for, so unit testing the class's dispose is a no-brainer. The outer try-finally style is atrocious.

BigFredd - braces are for teeth, curly braces are for coders. ;-)