Dealing with .NET IDisposable objects

Question

I work in C#, and I've been pretty lax about using using blocks to declare objects that implement IDisposable, which you're apparently always supposed to do. However, I don't see an easy way of knowing when I'm slipping up. Visual Studio doesn't seem to indicate this in any way (am I just missing something?). Am I just supposed to check help every time I declare anything, and gradually build up an encyclopedic memory for which objects are and which are not disposable? Seems unnecessary, painful, and error-prone.

How do you handle this?

EDIT:

Looking at the related questions sidebar, I found another question which made it clear that Dispose() is supposed to be called by the object's finalizer anyway. So even if you never call it yourself, it should eventually happen, meaning you won't have a memory leak if you don't use using (which is what I suppose I was really worried about all along). The only caveat is that the garbage collector doesn't know how much extra memory is being held by the object as unmanaged stuff, so it won't have an accurate idea how much memory will be freed by collecting the object. This will result in less-ideal-than-usual performance by the garbage collector.

In short, it's not the end of the world if I miss a using. I just wish something would generate at least a warning for it.

(Off-topic: why is there no special markdown for linking to another question?)

EDIT:

Ok, fine, stop clamoring. It's super duper all-fired dramatic-chipmunk-level important to call Dispose() or we'll all die.

Now. Given that, why is it so easy — hell, why is it even allowed — to do it wrong? You have to go out of your way to do it right. Doing it like everything else results in armageddon (apparently). So much for encapsulation, huh?

[Stalks off, disgusted]

Answer 1

FxCop might help (although it didn't spot a test I just fired at it); but yes: you are meant to check. IDisposable is simply such an important part of the system that you need to get into this habit. Using intellisense to look for .D is a good start (though not perfect).

However, it doesn't take long to familiarize yourself with types that need disposal; generally anything involving anything external (connection, file, database), for example.

ReSharper does the job too, offering a "put into using construct" option. It doesn't offer it as an error, though...

Of course, if you are unsure - try using it: the compiler will laugh mockingly at you if you are being paranoid:

using (int i = 5) {}  Error   1   'int': type used in a using statement must be implicitly convertible to 'System.IDisposable'     

Answer 2

If an object implements the IDisposable interface, then it is for a reason and you are meant to call it and it shouldn't be viewed as optional. The easiest way to do that is to use a using block.

Dispose() is not intended to only be called by an object's finalizer and, in fact, many objects will implement Dispose() but no finalizer (which is perfectly valid).

The whole idea behind the dispose pattern is that you are providing a somewhat deterministic way to release the unmanaged resources maintained by the object (or any object in it's inheritance chain). By not calling Dispose() properly you absolutely can run in to a memory leak (or any number of other issues).

The Dispose() method is not in any way related to a destructor. The closest you get to a destructor in .NET is a finalizer. The using statement doesn't do any deallocation...in fact calling Dispose() doesn't do any deallocation on the managed heap; it only releases unmanaged resources that had been allocated. The managed resources aren't truely deallocated until the GC runs and collects the memory space allocated to that object graph.

The best ways to determine if a class implements IDisposable are:

• IntelliSense (if it has a Dispose() or a Close() method)
• MSDN
• Reflector
• Compiler (if it doesn't implement IDisposable you get a compiler error)
• Common sense (if it feels like you should close/release the object after you're done, then you probably should)
• Semantics (if there is an Open(), there is probably a corresponding Close() that should be called)
• The compiler. Try placing it in a using statement. If it doesn't implement IDisposable, the compiler will generate an error.

Think of the dispose pattern as being all about scope lifetime management. You want to acquire the resource as last as possible, use as quickly as possibly, and release as soon as possible. The using statement helps to do this by ensuring that a call to Dispose() will be made even if there are exceptions.