Disposal Anxiety

Monday, November 8, 2004
I came across this again in the newsgroups today:

 
sqlConnection.Close();
sqlConnection.Dispose();
sqlConnection = null;
 

There has been plenty of debate about the confusion resulting from aliasing the Dispose method. There has also been heaps of information to explain finalization, garbage collection, connection pooling, and IDisposable. Still, none of the debate or information addresses the fundamental problem in this scenario.

For some developers, the instantiation of a disposable object results in high levels of anxiety. The anxiety produces the obsessive-compulsive behavior demonstrated in the above code snippet.

I have a solution to propose. The using keyword only works well for the passive-aggressive types (I’ll dispose the object, but only as a side-effect), while those calling Dispose or Close explicitly do so with a clean and clinical approach – there is no emotion involved.

What the IDisposable interface needs is a method that promotes self-efficacy in a developer. A method name that can stir up primal urges as the developer types. What we need is a method like die_you_gravy_sucking_pigdog() from BSD’s shutdown.c module.

Now, I know this function was written back in the days when steam engines still ruled the world, but we could modernize the function by applying some .NET naming standards.

sqlConnection.DieYouGravySuckingPigDog();

Can you feel the passion behind this statement? This statement carries the emotion that is hard to find in today's code. I hope you’ll support this proposal. Good people will be able to sleep at night once again.


Comments
Andy Tuesday, November 9, 2004
I think the confusion for me comes from the fact that in some things Dispose() does the exact same thing as Close(). But in others like your example sqlConnection.Dispose() not only closes it but also frees up the resources so you can't use it again. Where as sqlConnection.Close() simply closes the connection and it can be re-used later on if opened up again properly. The way the sqlConnection works is how I would think everything should work. It is intuitive to me that way. Close closes and Dispose disposes it makes perfect sense.
<br>
<br>However I think people who code the above type of code snipet you posted are probably used to getting fubared by Disposes and Closes that do the same thing so they call everything just in case.
<br>
<br>Have you ever used COM from C++ ? If you have you know you see a lot of the same type of thing trying to make sure you closed, freed, derefed, and nulled stuff after you incremented it's count by connecting to it. COM was supposed to be another one of those things where people would do the right thing by calling addRef and Release but people didn't.
<br>
<br>A while back you posted an example using a using statement. Can you do the same with this and it will get cleaned up or does it only get closed if you use a using?
<br>
<br>yet another reason I really dislike some things about .Net it is quickly becoming as bloated as COM with no end in site. Constantly I hear stuff like:
<br>
<br>&quot;oh you mean you didn't know that if you hop on one leg and call Close from within a static Full-Moon phase of the forth bog rock near the runestone of Akbarad, then recite the Koran backwards in Icelandic it will Close and Cleanup your IWhatTheFuck connection? I do it that way all the time cause I have no life and I read the 250,000 page .Net for Druids, Sorcerers, bogWumps, and assorted undead and I saw it on page 153,467. It was in the C# undocumented gotchas, programming tips, and good recipes for old bat wings section on the left of the page.&quot;
<br>
<br>A good abstraction should take away complexity and give the implementer more power and flexibility. So far .Net is fast climbing my list of bad abstractions. Currently it's number 4 the other's are MFC, COM, and Java's generics. In that order. Give me some more time with it and it may climb up near COM the way it's been going lately.
Shawn B. Tuesday, November 9, 2004
I understand thier concept for deterministic finalization and all its benefits and so on so forth. I just don't see why it is so difficult for them to have it call dispose when you make an object null automatically. Then, we wouldn't have these problems. We can close or set the object null and not worry about it.
<br>
<br>But MS knows best, right? They say that we should just call Dispose(). But if we are going to write that line of code (or possible forget it and cause a memory leak in the case of an unhandled exception) everytime before setting it null anyway, I don't see the difference. Of course, they'll tell us we don't need to set the object to null (which really just resets it to its original state) because of the garbage collector.
<br>
<br>The problem is that there is so much code where people are &quot;used to&quot; the &quot;old way&quot; and that isn't going to change. I know the rules quite well and its hard for me to come to grips with (probly because I still code C++ and VB6 which requires that kind of thing).
<br>
<br>But I agree, it can be confusing.
Scott Allen Wednesday, November 10, 2004
Shawn, Andy:
<br>
<br>Yep, it's certainly a head spinner. I'd still take it over consuming COM components from C++ anyday though. The using statement can take care of these things for you, I use it everywhere I can.
<br>
<br>
Bill Sunday, November 14, 2004
The million dollar point is that you should use using(SqlConnection cn = new SqlConnection) (unless you use VB.NET, in which case you should use C# - I mean a try/catch/finally method).
<br>
<br>The amount of BS that's floating around out there about this stuff is mind bending. Glad you posted it.
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!