Should “Dispose” only be used for types containing unmanaged resources?

Question

I was having a discussion with a colleague recently about the value of Dispose and types that implement IDisposable.

I think there is value

Answer 1

No, it's not only for unmanaged resources.

It's suggested like a basic cleanup built-in mechanism called by framework, that enables you possibility to cleanup whatever resource you want, but it's best fit is naturally unmanaged resources management.

Answer 2

Your Type should implement IDisposable if it references unmanaged resources or if it holds references to objects that implement IDisposable.

Answer 3

In one of my projects I had a class with managed threads inside it, we'll call them thread A, and thread B, and an IDisposable object, we'll call it C.

A used to dispose of C on exiting. B used to use C to save exceptions.

My class had to implement IDisposable and a descrtuctor to ensure things are disposed of in the correct order. Yes the GC could clean up my items, but my experience was there was a race condition unless I managed the clean up of my class.

Answer 4

I think it's most helpful to think of IDisposable in terms of responsibilities. An object should implement IDisposable if it knows of something that will need to be done between the time it's no longer needed and the end of the universe (and preferably as soon as possible), and if it's the only object with both the information and impetus to do it. An object which opens a file, for example, would have a responsibility to see that the file gets closed. If the object were to simply disappear without closing the file, the file might not get closed in any reasonable timeframe.

It's important to note that even objects which only interact with 100% managed objects can do things that need to be cleaned up (and should use IDisposable). For example, an IEnumerator which attaches to a collection's "modified" event will need to detach itself when it is no longer needed. Otherwise, unless the enumerator uses some complex trickery, the enumerator will never be garbage-collected as long as the collection is in scope. If the collection is enumerated a million times, a million enumerators would get attached to its event handler.

Note that it's sometimes possible to use finalizers for cleanup in cases where, for whatever reason, an object gets abandoned without Dispose having been called first. Sometimes this works well; someitmes it works very badly. For example, even though Microsoft.VisualBasic.Collection uses a finalizer to detach enumerators from "modified" events, attempting to enumerate such an object thousands of times without an intervening Dispose or garbage-collection will cause it to get very slow--many orders of magnitude slower than the performance that would result if one used Dispose correctly.

Answer 5

Dispose should be used for any resource with a limited lifetime. A finalizer should be used for any unmanaged resource. Any unmanaged resource should have a limited lifetime, but there are plenty of managed resources (like locks) that also have limited lifetimes.

Answer 6

While there are good answers to this already, I just wanted to make something explicit.

There are three cases for implementing IDisposable:

1. You are using unmanaged resources directly. This typically involves retrieving an IntPrt or some other form of handle from a P/Invoke call that has to be released by a different P/Invoke call
2. You are using other IDisposable objects and need to be responsible for their disposition
3. You have some other need of or use for it, including the convenience of the using block.

While I might be a bit biased, you should really read (and show your colleague) the StackOverflow Wiki on IDisposable.