469,645 Members | 1,682 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,645 developers. It's quick & easy.

Always dispose of an object that implements the IDisposible interface?

If an object implements the IDisposable interface (regardless if its a
framework object or a user object), should I always dispose of that
object out of principle?
Nov 16 '05 #1
16 4034
"Daniel Mori" <sb******@hotmail.com> wrote:
If an object implements the IDisposable interface
(regardless if its a framework object or a user
object), should I always dispose of that object
out of principle?


If a class implements IDisposable, it almost certainly has resources
that need freeing up - so yes, you should. A 'using' block will ensure
that you don't forget to do this:

using (DisposableThing x = new DisposableThing())
{
// ... do something with x ...
}

P.
Nov 16 '05 #2
"Paul E Collins" <fi******************@CL4.org> wrote in message
news:cl**********@hercules.btinternet.com...
If a class implements IDisposable, it almost certainly has resources
that need freeing up - so yes, you should. A 'using' block will ensure
that you don't forget to do this:


I don't know if this is always true. For example the sqlConnection can just
be closed.

Michael Culley
Nov 16 '05 #3
"Michael Culley" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:u3**************@TK2MSFTNGP11.phx.gbl...
"Paul E Collins" <fi******************@CL4.org> wrote in message
news:cl**********@hercules.btinternet.com...
If a class implements IDisposable, it almost certainly has resources
that need freeing up - so yes, you should. A 'using' block will ensure
that you don't forget to do this:


I don't know if this is always true. For example the sqlConnection can
just
be closed.


Today, the only thing that SqlConnection's Dispose method does is make sure
the connection is closed. Tomorrow, it could do something else. If you
want to be a good citizen, call Dispose and pretend that you don't know what
it does.
Nov 16 '05 #4

"John Vottero" <Jo**@mvpsi.com> wrote in message
news:eW**************@tk2msftngp13.phx.gbl...
"Michael Culley" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:u3**************@TK2MSFTNGP11.phx.gbl...
"Paul E Collins" <fi******************@CL4.org> wrote in message
news:cl**********@hercules.btinternet.com...
If a class implements IDisposable, it almost certainly has resources
that need freeing up - so yes, you should. A 'using' block will ensure
that you don't forget to do this:


I don't know if this is always true. For example the sqlConnection can
just
be closed.


Today, the only thing that SqlConnection's Dispose method does is make
sure the connection is closed. Tomorrow, it could do something else. If
you want to be a good citizen, call Dispose and pretend that you don't
know what it does.


When dealing with objects that use the Close pattern, Close and Dispose
*should* be, at least, functionally similar, any that are not are broken(I
think SqlConnection itself is one which differs its implementations, leading
to some annoyance). IDisposable is provided to allow using and other such
statements\frameworks to formazlie access to the disposal method, but in
itself offers no more guarentees than Close does. There is no real need to
call dispose on objects that provide a Close method as a matter of common
practice, if not standard per se. Remember, there is no guarentee that
Dispose will actually do any good or will be the right method to use. If a
Close method is provided, it likely is well thought out and should be used
when not using the using statement, otherwise the class designer wouldn't
have included it(in most cases Dispose will be explicitly implemented when
Close is appropriate, and a cast call is almost certainly the wrong thing to
do).

There is a reason Close exists period, and its not just to look pretty.
Using using is usually the better pattern, but that is a matter of design
and appropriatness, not requirements.
Nov 16 '05 #5
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uL**************@TK2MSFTNGP11.phx.gbl...
When dealing with objects that use the Close pattern, Close and Dispose
*should* be, at least, functionally similar, any that are not are broken(I
think SqlConnection itself is one which differs its implementations, leading to some annoyance).


I would expect that close might raise exceptions under some situations where
dispose did not. This was the case with vb6 where closing a recordset would
raise an error if an update was no committed but setting it to nothing would
ignore the error.
Nov 16 '05 #6

"Daniel Mori" <sb******@hotmail.com> wrote in message
news:d2************************@posting.google.com ...
If an object implements the IDisposable interface (regardless if its a
framework object or a user object), should I always dispose of that
object out of principle?


You should always dispose the object if the object implements IDisposable
*and* you own the object (in other words, you know that no-one else is going
to use the object after you are done with it).

Regards,
Sami
Nov 16 '05 #7
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:uL****************@TK2MSFTNGP11.phx.gbl...

"John Vottero" <Jo**@mvpsi.com> wrote in message
news:eW**************@tk2msftngp13.phx.gbl...
"Michael Culley" <mc*****@NOSPAMoptushome.com.au> wrote in message
news:u3**************@TK2MSFTNGP11.phx.gbl...
"Paul E Collins" <fi******************@CL4.org> wrote in message
news:cl**********@hercules.btinternet.com...
If a class implements IDisposable, it almost certainly has resources
that need freeing up - so yes, you should. A 'using' block will ensure
that you don't forget to do this:

I don't know if this is always true. For example the sqlConnection can
just
be closed.

Today, the only thing that SqlConnection's Dispose method does is make
sure the connection is closed. Tomorrow, it could do something else. If
you want to be a good citizen, call Dispose and pretend that you don't
know what it does.


When dealing with objects that use the Close pattern, Close and Dispose
*should* be, at least, functionally similar, any that are not are broken(I


I would expect Close to be a subset of Dispose.
think SqlConnection itself is one which differs its implementations,
leading to some annoyance). IDisposable is provided to allow using and
other such statements\frameworks to formazlie access to the disposal
method, but in itself offers no more guarentees than Close does. There is
no real need to call dispose on objects that provide a Close method as a
matter of common practice, if not standard per se. Remember, there is no
guarentee that Dispose will actually do any good or will be the right
method to use. If a Close method is provided, it likely is well thought
out and should be used when not using the using statement, otherwise the
class designer wouldn't have included it(in most cases Dispose will be
explicitly implemented when Close is appropriate, and a cast call is
almost certainly the wrong thing to do).

There is a reason Close exists period, and its not just to look pretty.
Using using is usually the better pattern, but that is a matter of design
and appropriatness, not requirements.


It's just wrong to believe that if an object has a Close method, that method
does the same thing as Dispose. It's also wrong to believe that there's no
need to call an object's Dispose method because you know what Dispose does.

Nov 16 '05 #8
On Mon, 25 Oct 2004 16:17:52 -0400, "John Vottero" <Jo**@mvpsi.com>
wrote:

It's just wrong to believe that if an object has a Close method, that method
does the same thing as Dispose. It's also wrong to believe that there's no
need to call an object's Dispose method because you know what Dispose does.


Unfortunately, this is exactly what the parts of the framework want
people to think (we don't want people to think they have to Dispose a
FileStream, so let's implement IDisposable explicitly and provide a
Close method for everyone to call). The end result has been massive
amounts of confusion.

--
Scott
http://www.OdeToCode.com/blogs/scott/
Nov 16 '05 #9
>>>
Today, the only thing that SqlConnection's Dispose method does is make
sure the connection is closed. Tomorrow, it could do something else.
If you want to be a good citizen, call Dispose and pretend that you
don't know what it does.


When dealing with objects that use the Close pattern, Close and Dispose
*should* be, at least, functionally similar, any that are not are
broken(I


I would expect Close to be a subset of Dispose.


Why? There is *no* convention that says so. Infact DIspose is there to
"pefrom application-defined tasks associated with freeing, releasing, or
resetting unmanaged resources"(paraphrased from MSDN), that sounds more like
a subset of Close to me.

For all you know dispose does not close the object or does anything else
similar to Close. The only saving grace Dispose has is that, as common
practice, Dispose and Close are similar or identical. In any other case you
end up with broken API's and a useless IDisposable contract.

If Close is anything but an equal to Dispose you end up with scenarios where
users are forced to know what each means and to apply each particular method
in the circumstance nessecery. That ends you with two seperate states
(Closed and Disposed), increasing possible exceptions and the complete
complexity of the class itself. You end up with circumstances where objects
are only cleaned up due to one path while the other causes surprises. You
end up with scenarios where you cannot use using. In effect, if Close and
Dispose aren't considered equal, you risk Dispose having Reset or Free and
Reload sematics instead of Close semantics.

There is a reason Close exists period, and its not just to look pretty.
Using using is usually the better pattern, but that is a matter of design
and appropriatness, not requirements.


It's just wrong to believe that if an object has a Close method, that
method does the same thing as Dispose. It's also wrong to believe that
there's no need to call an object's Dispose method because you know what
Dispose does.


And by that logic it is equally wrong to assume that because an object has a
Dispose method that you can call it instead of Close. You cannot rely on
Dispose anymore than Close, guess its best to call both every time, eh? For
that matter, you can't even safely call Dispose if you don't know what it
does because that may *reset* the content without flushing buffers or do
things which makes close illogical or surprising(like recycling
connections). If you cannot know these things, you cannot expect Dispose to
correctly close the object. If you cannot expect Dispose to close the object
you cannot expect Dispose to be a safe pattern.

Would it surprise you to know that there are many people who believe
IDisposable was a pattern that should never have been let loose? I don't
happen to agree to an extreme extent, but I do believe its one that an end
user should never be forced to directly call into and that the literal
definition is far too narrow to make the pattern really useful. It is only
useful as a pattern to formalize Close semantics for use by compilers and
frameworks; anything more stretches the usefulness of the pattern. Sadly,
the existing specified contract does not even fulfill that, even though that
is how IDisposable is usually used.
Nov 16 '05 #10

"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:9l********************************@4ax.com...
On Mon, 25 Oct 2004 16:17:52 -0400, "John Vottero" <Jo**@mvpsi.com>
wrote:

It's just wrong to believe that if an object has a Close method, that
method
does the same thing as Dispose. It's also wrong to believe that there's
no
need to call an object's Dispose method because you know what Dispose
does.


Unfortunately, this is exactly what the parts of the framework want
people to think (we don't want people to think they have to Dispose a
FileStream, so let's implement IDisposable explicitly and provide a
Close method for everyone to call). The end result has been massive
amounts of confusion.


And yet, MemoryStream has no reason to be IDisposable under the contract of
IDisposable. It simply does not do what it should. IDisposable is nearly
broken and virtually no one implements it within the confines of the actual
interface meaning. IDisposable should be explicitly implemented in streams
and should never be called directly. It should not be used to close an
object and for MemoryStream, by all rights, it should be a nop. It is not
however, and as I've argued before, the only thing that makes IDisposable
valid is that it has been inextricably tied to Close semantics by the
framework and common practice. Any other usage of IDisposable is bound to
cause greater confusion that a Close method ever will.

Beyond that, I've yet to see anything near "massive amounts of confusion"
over Close. I've seen many over issues with IDisposable, but almost all of
those have nothing to do with a matching Close method. It is a minor issue
in a system where IDisposable is rarely actually implemented within its own
rules anyway. Perhaps the confusion really is because of IDisposable and not
Close methods?

And perhaps people saying "always use dispose and forget everything else" is
contributing more to the problems than it is anything else.
Nov 16 '05 #11
On Mon, 25 Oct 2004 21:11:33 -0500, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

Beyond that, I've yet to see anything near "massive amounts of confusion"
over Close. I've seen many over issues with IDisposable, but almost all of
those have nothing to do with a matching Close method. It is a minor issue
in a system where IDisposable is rarely actually implemented within its own
rules anyway. Perhaps the confusion really is because of IDisposable and not
Close methods?


Hi Daniel:

Yes, I think the epicenter of the confusion is centered directly on
top of the IDisposable interface, and the closer one sits to the
surface of the interface the greater the tremors are. Classes like
SqlConnection, having both Close and Dispose methods, have been
hotbeds of endless debate in newsgroups, mailing lists, and user group
meetings.

--
Scott
http://www.OdeToCode.com/blogs/scott/
Nov 16 '05 #12
"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:en********************************@4ax.com...
On Mon, 25 Oct 2004 21:11:33 -0500, "Daniel O'Connell [C# MVP]"
<onyxkirx@--NOSPAM--comcast.net> wrote:

Beyond that, I've yet to see anything near "massive amounts of confusion"
over Close. I've seen many over issues with IDisposable, but almost all of
those have nothing to do with a matching Close method. It is a minor issue
in a system where IDisposable is rarely actually implemented within its
own
rules anyway. Perhaps the confusion really is because of IDisposable and
not
Close methods?


Hi Daniel:

Yes, I think the epicenter of the confusion is centered directly on
top of the IDisposable interface, and the closer one sits to the
surface of the interface the greater the tremors are. Classes like
SqlConnection, having both Close and Dispose methods, have been
hotbeds of endless debate in newsgroups, mailing lists, and user group
meetings.


I don't understand the confusion or the debate. When you want to close a
SqlConnection, call close. When you're done with an SqlConnection, call
Dispose. The call sequence is:

new
Open
...
Close
Open
...
Close
Open
...
Close
Open
...
Close
Dispose

Is it confusing because Dispose makes sure you called that last Close? (at
least, for SqlConnection) Would it be better if Dispose threw an exception
if the connection wasn't closed?
Nov 16 '05 #13
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:OW**************@TK2MSFTNGP09.phx.gbl...

Today, the only thing that SqlConnection's Dispose method does is make
sure the connection is closed. Tomorrow, it could do something else.
If you want to be a good citizen, call Dispose and pretend that you
don't know what it does.
When dealing with objects that use the Close pattern, Close and Dispose
*should* be, at least, functionally similar, any that are not are
broken(I
I would expect Close to be a subset of Dispose.


Why? There is *no* convention that says so. Infact DIspose is there to
"pefrom application-defined tasks associated with freeing, releasing, or
resetting unmanaged resources"(paraphrased from MSDN), that sounds more
like a subset of Close to me.


I realize that but there's also *no* convention that says that Close is in
any way related to Dispose.

For all you know dispose does not close the object or does anything else
similar to Close. The only saving grace Dispose has is that, as common
practice, Dispose and Close are similar or identical. In any other case
you end up with broken API's and a useless IDisposable contract.
Exactly! When I want to close an object, I call Close. When I'm done with
it, I call Dispose. Don't assume that the two are related.

If Close is anything but an equal to Dispose you end up with scenarios
where users are forced to know what each means and to apply each
particular method in the circumstance nessecery.
Is it unreasonable to ask users to know what methods do before they start
calling them?
That ends you with two seperate states (Closed and Disposed), increasing
possible exceptions and the complete complexity of the class itself.
But, there *are* two seperate states!
You end up with circumstances where objects are only cleaned up due to one
path while the other causes surprises. You end up with scenarios where you
cannot use using. In effect, if Close and Dispose aren't considered equal,
you risk Dispose having Reset or Free and Reload sematics instead of Close
semantics.
I do think of Dispose as free. If an object implements IDisposable, call
Dispose when you're done with it or you might leak "things". I see no
relationship to Close.

There is a reason Close exists period, and its not just to look pretty.
Using using is usually the better pattern, but that is a matter of
design and appropriatness, not requirements.
It's just wrong to believe that if an object has a Close method, that
method does the same thing as Dispose. It's also wrong to believe that
there's no need to call an object's Dispose method because you know what
Dispose does.


And by that logic it is equally wrong to assume that because an object has
a Dispose method that you can call it instead of Close. You cannot rely on


I never said that. When you want to close an object, call Close. When
you're done with it, call Dispose.
Dispose anymore than Close, guess its best to call both every time, eh?
For
Yes.
that matter, you can't even safely call Dispose if you don't know what it
does because that may *reset* the content without flushing buffers or do
things which makes close illogical or surprising(like recycling
connections). If you cannot know these things, you cannot expect Dispose
to correctly close the object. If you cannot expect Dispose to close the
object you cannot expect Dispose to be a safe pattern.
I *don't* expect Dispose to correctly close an object. Nor do I expect free
to close an object in a C++ program.

Would it surprise you to know that there are many people who believe
IDisposable was a pattern that should never have been let loose? I don't
happen to agree to an extreme extent, but I do believe its one that an end
user should never be forced to directly call into and that the literal
definition is far too narrow to make the pattern really useful. It is only
useful as a pattern to formalize Close semantics for use by compilers and
frameworks; anything more stretches the usefulness of the pattern. Sadly,
the existing specified contract does not even fulfill that, even though
that is how IDisposable is usually used.

Nov 16 '05 #14
Hi John:

The debate arises because in many cases the class designers have
offered the Close method as an alias for the Dispose method, thus
giving Close the same semantics as Dispose.

On aliasing the Dispose name...
http://blogs.msdn.com/brada/archive/.../06/50127.aspx

If you check around Angel Saenz-Badillos ADO.NET blog, you'll see the
terms Close and Dispose are used interchangably (often reffered to as
Close/Dispose).
http://blogs.msdn.com/angelsb/

Looking in the ASP.NET and ADO.NET newsgroups and forms over the years
I've seen people divide into the following camps:

The first camp says just invoke Dispose, or wrap the connection inside
of a using scope.

The second camp says just invoke the Close method.

The third camp insists on calling Close and Dispose.

The fourth camp says call Close, then Dispose, then set the object
reference to null or Nothing to make sure it's really, really, really,
dead.

At a presentation I did a couple weeks ago there was also a gentleman
who insisted you had to call Close twice - once inside a try block and
once inside a finally block.

As for your questions at the end: I personally would not want an
exception thrown if the connection was still open when I call Dispose.
I want Dispose to work in conjunction with the using statement and
just take care of all the work needed to tidy up after an object.

--
Scott
http://www.OdeToCode.com/

On Tue, 26 Oct 2004 11:53:14 -0400, "John Vottero" <Jo**@mvpsi.com>
wrote:

I don't understand the confusion or the debate. When you want to close a
SqlConnection, call close. When you're done with an SqlConnection, call
Dispose. The call sequence is:

new
Open
...
Close
Open
...
Close
Open
...
Close
Open
...
Close
Dispose

Is it confusing because Dispose makes sure you called that last Close? (at
least, for SqlConnection) Would it be better if Dispose threw an exception
if the connection wasn't closed?


Nov 16 '05 #15

"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:u4********************************@4ax.com...
Hi John:

The debate arises because in many cases the class designers have
offered the Close method as an alias for the Dispose method, thus
giving Close the same semantics as Dispose.

On aliasing the Dispose name...
http://blogs.msdn.com/brada/archive/.../06/50127.aspx

Stream does add confusion because it hides Dispose.
If you check around Angel Saenz-Badillos ADO.NET blog, you'll see the
terms Close and Dispose are used interchangably (often reffered to as
Close/Dispose).
http://blogs.msdn.com/angelsb/

Looking in the ASP.NET and ADO.NET newsgroups and forms over the years
I've seen people divide into the following camps:

The first camp says just invoke Dispose, or wrap the connection inside
of a using scope.

The second camp says just invoke the Close method.

The third camp insists on calling Close and Dispose.

The fourth camp says call Close, then Dispose, then set the object
reference to null or Nothing to make sure it's really, really, really,
dead.


Count me in this camp!

Nov 16 '05 #16

"John Vottero" <Jo**@mvpsi.com> wrote in message
news:e5**************@TK2MSFTNGP12.phx.gbl...

"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:u4********************************@4ax.com...
Hi John:

The debate arises because in many cases the class designers have
offered the Close method as an alias for the Dispose method, thus
giving Close the same semantics as Dispose.

On aliasing the Dispose name...
http://blogs.msdn.com/brada/archive/.../06/50127.aspx


Stream does add confusion because it hides Dispose.
If you check around Angel Saenz-Badillos ADO.NET blog, you'll see the
terms Close and Dispose are used interchangably (often reffered to as
Close/Dispose).
http://blogs.msdn.com/angelsb/

Looking in the ASP.NET and ADO.NET newsgroups and forms over the years
I've seen people divide into the following camps:

The first camp says just invoke Dispose, or wrap the connection inside
of a using scope.

The second camp says just invoke the Close method.

The third camp insists on calling Close and Dispose.

The fourth camp says call Close, then Dispose, then set the object
reference to null or Nothing to make sure it's really, really, really,
dead.


Count me in this camp!


....and then there's the "Hey! Let's check it out!" camp. Meaning use Ildasm
and the debugger to see what actually happens when using an
instance/combination of using/Close/Dispose is called. We might not want to
do this everytime we DESIGN something, but certainly as we get ready for its
release.
Nov 16 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by RiteshDotNet | last post: by
3 posts views Thread by Maxim | last post: by
16 posts views Thread by Jeremy | last post: by
44 posts views Thread by Smokey Grindle | last post: by
6 posts views Thread by =?Utf-8?B?VmljdG9y?= | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.