close() and dispose()

  • Thread starter Thread starter Eric B.
  • Start date Start date
I always do close & dispose.

It might clear up the memory allocation. But if you're inside a
private method, it will probably get destroy once you leave that
method.
 
I always do   close & dispose.

It might clear up the memory allocation.
Click to expand...

No it won't.
But if you're inside a
private method, it will probably get destroy once you leave that
method.
Click to expand...

No it won't.

Close() and Dispose() don't release memory. They may occasionally
release references that they may have to other objects, but unless
they then explicitly call GC.Collect() - which would be a bad idea -
that's not going to release any memory.

Personally I just use a "using" block which will automatically call
Dispose(), and don't worry about Close(). If I ever come across a type
which implements IDisposable but which I need to explicitly Close() in
common situations, I'll complain to the author.

Jon
 
On Oct 9, 9:05 am, "Peter Duniho" <[email protected]>
wrote:

But personally, I tend to always do both.  To me, the two are semantically  
different, even if they often wind up doing the same thing in practice.
Click to expand...

Do you Close() in a finally block, or just at the end of the normal
execution?

I don't see the benefit of explicitly calling Close() if Dispose() is
going to do everything I want - which in my experience it does with
every disposable type I've been interested in. It's just more clutter
for no reason - I explicitly indicate that I want to scope-limit the
resource usage with a "using" statement; anything else is extraneous
IMO.

Jon
 
If you can reopen something then I would use Close(), but only if I intended
to reopen. If I intend to finish with the object completely I would ONLY
call Dispose. The reason is that if Dispose is implemented properly (and it
should be) then it will do everything Close() does plus possibly more.

x.Close();
x.Dispose();

You are wasting your life typing it :-)
 
Alvin said:
If memory serves me correctly, some cases such as streams close calls
dispose, for most others dispose calls close. Call both is an exercise
in futility roughly equivalent to setting an int variable to 0 after
using it - well that's a stretch. Like Jon, I use the using statement
and let the framework figure out which call is prudent.
Click to expand...

For some classes, like a file stream, there is no difference between
calling Close and calling Dispose. You can't reopen the stream once it's
closed, you have to open a new stream. Those classes could call Dispose
from the Close method as you mention.

For some other classes, like a database connection, there is a
difference. If you close the connection, you can reopen it again, which
should use slightly less resources than creating a new one. Once you
have disposed the connection object, you can't use it any more.
 
If you can reopen something then I would use Close(), but only if I intended
to reopen.  If I intend to finish with the object completely I would ONLY
call Dispose.  The reason is that if Dispose is implemented properly (and it
should be) then it will do everything Close() does plus possibly more.
Click to expand...

Ditto. That is exactly what I do as well.
 
No it won't.


No it won't.

Close() and Dispose() don't release memory. They may occasionally
release references that they may have to other objects, but unless
they then explicitly call GC.Collect() - which would be a bad idea -
that's not going to release any memory.

Personally I just use a "using" block which will automatically call
Dispose(), and don't worry about Close(). If I ever come across a type
which implements IDisposable but which I need to explicitly Close() in
common situations, I'll complain to the author.

Jon
Click to expand...

One clarification...both Close and Dispose often do release unmanaged
memory though.
 
For some classes, like a file stream, there is no difference between
calling Close and calling Dispose. You can't reopen the stream once it's
closed, you have to open a new stream. Those classes could call Dispose
from the Close method as you mention.

For some other classes, like a database connection, there is a
difference. If you close the connection, you can reopen it again, which
should use slightly less resources than creating a new one. Once you
have disposed the connection object, you can't use it any more.
Click to expand...

All of that is true - but I personally have never used that
functionality in any disposable class I've come across. Simple
database connection pooling has always been fine for me :)

If I *did* start relying on the difference between Close and Dispose
somewhere, I'd want to include a big comment explaining why, so that a
maintenance developer (possibly me!) didn't change it later and
inadvertently break something.

Jon
 
Peter Duniho said:
I close inside the finally block.
Click to expand...

Which means life is as bad as Java, without a using statement :(
Absent a mandate in the .NET specifications, it's not guaranteed
behavior.
Click to expand...

True in a general sense. Not true on a per-type basis, of course - and
I think any type which didn't act appropriately when being disposed
would be severely criticised, to be honest.
And it's worse to forget to close or dispose something that
needed to be than to do both when one would suffice. I find it annoying
to have to keep going back to the docs just to make sure I remembered the
behavior correctly for a specific class (heaven knows I mis-remember all
sorts of other things), so I just do both when both makes sense and leave
it at that.
Click to expand...

I think I've checked out all the classes which I care about and come to
the view that there aren't any differences I'm worried about. I'd
rather have the more readable code.

<snip>
 
Peter Duniho said:
As bad as? Oh, come on. I think you're exaggerating, quite a lot.
Adding the extra call to Close() doesn't do anything like make C# "as bad
as" Java (not that I think Java is that bad anyway, but certainly I find
.NET/C# much nicer).
Click to expand...

I meant in terms of this particular aspect - I've always found it
amazing how much difference the using statement makes to readability,
virtually eliminating try/finally blocks. As those are much more common
than try/catch blocks (particularly in .NET where you don't need to
convert exceptions all the time due to checked exception rules) I
suspect my density of explicit try blocks in C# is way, way lower than
in Java.

I'd need hard evidence that relying on Dispose was actually costing me
something before I'd effectively give us the using statement :)
In any case, the kind of code I work on this doesn't come up much. Maybe
if I were dealing with these classes a lot I'd have a different opinion.
But I don't, and I don't. :p
Click to expand...

:)
 
Brian said:
One clarification...both Close and Dispose often do release unmanaged
memory though.
Click to expand...

Dispose always does (if it's implemented correctly of couse).

Close may or may not do that, depending on what it's supposed to do. The
Close method for a database connection for example allows the connection
to be reopened later, while the Dispose method frees the resources that
allows that.
 
The point is that some objects implement a Close() method just because it
makes more sense logically than Dispose. For example FileStream.Close()
means more to me than FileStream.Dispose(). If an object has a Close()
method and doesn't call it from Dispose I would consider that to be poor
programming, or at the very least confusing!

I can see however that in a pooled collection of SomeThing you might want
Dispose to return it to the pool and Close to actually kill it off, but I
would *still* consider this confusing. I'd be more inclined to implement
Activate/Deactivate or IsActive instead of Open/Close. My original
statement was that *if* the object implements Close in such a way that the
object may be re opened then I would only call Close if I intended to later
reopen it. Otherwise I would always dispose of it (actually via the using
statement).
 
Back
Top