I stumbled upon a blog post by Kim Hamilton on When To Call Dispose. The most interesting part about the post is that this is from someone who works on the Base Class Libraries team. The following part is especially striking:
A recent internal email thread unearthed extreme differences of opinion about when Dispose(void) should be called on an IDisposable. The rival suggestions were:1. Always call Dispose2. Avoid calling Dispose; rely on cleanup at finalizationThis led to a long discussion and a realization that -- while it seems like we’ve said everything there is to say about Dispose -- it’s time for some more Dispose guidance.
I don't know about you guys, but the thought of Base Class Library developers not being sure on when Dispose should be called is something that makes me quite uncomfortable. If anyone should know, it's these guys, right?
Another interesting quote from the post:
Whatever distinction we eventually use, API docs should explicitly call out IDisposables that must be Disposed.
Great... now we are supposed to rely on the MSDN docs to find out which IDisposables need to be disposed and which ones don't.
I kinda like the IDisposable pattern, but it's truly a shame that there are so many types that implement the IDisposable interface without really needing to implement it. I've always considered the IDisposable interface to be a contract which states "if you use me, you must dispose me". For certain types, this is true. Unfortunately, for other types that implement the interface it's not true even though the IDisposable documentation is pretty clear about this:
When calling a class that implements the IDisposable interface, use the try/finally pattern to make sure that unmanaged resources are disposed of even if an exception interrupts your application.
In a perfect .NET world, there would be no types implementing IDisposable without actually requiring disposal (IMHO). Again, i think the interface is a contract that must be followed by everyone who makes use of it. Then again, it does feel pretty pointless to dispose types of which you know that it really doesn't make a difference.
The introduction of explicit Code Contracts in .NET 4.0, got me thinking about trying to make disposal of types that really require it enforced by the compiler. What i have in mind is not possible with the Code Contracts in .NET 4.0, but it's something that i think would be a good addition to the .NET Framework.
Suppose we could do the following:
[RequiresDisposal]
public class MyDisposableType : IDisposable
{
public void DoSomething()
{
// does something really cool and/or important
}
public void Dispose()
{
// this would contain an important disposable implementation
}
}
Basically just a type which implements IDisposable, and there's an attribute that specifies that the disposal of this type is really required. The following code should then fail to compile:
private void SomeMethod()
{
new MyDisposableType().DoSomething();
}
Whereas this code would compile without errors:
private void SomeMethod()
{
using (var disposableType = new MyDisposableType())
{
disposableType.DoSomething();
}
}
It's just a thought and obviously, this isn't possible right now. But i think it would be great if it were possible. We could do all sorts of things with this approach... for instance, if an object owns a reference to an IDisposable type which has the [RequiresDisposal] attribute, the compiler could enforce that the object owning the reference must implement IDisposable and have the [RequiresDisposal] attribute as well. I think we'd end up with a system were types that really require disposal can't be used without properly disposing them.
Thoughts?
Pingback: Dew Drop - November 17, 2008 | Alvin Ashcraft's Morning Dew