Is it a bad idea to do both once I'm done with an object?

Eric B.

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.


On Oct 9, 12:32*am, "Eric B." <bigb...@sesamestreet.com> wrote:
> Is it a bad idea to do both once I'm done with an object?
>
> Eric B.

On Oct 9, 9:00*am, Slickuser <slick.us...@gmail.com> wrote:
> I always do * close & dispose.
>
> It might clear up the memory allocation.

No it won't.

> But if you're inside a
> private method, it will probably get destroy once you leave that
> method.

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" <NpOeStPe...@nnowslpianmk.com>
wrote:

<snip>

> 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.

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 :-)



--
Pete
====
http://mrpmorris.blogspot.com
http://www.capableobjects.com

Alvin Bruney [ASP.NET MVP] wrote:
> 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.
>

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.

--
Göran Andersson
_____
http://www.guffa.com

On Oct 9, 3:36*am, "Peter Morris" <mrpmorri...@SPAMgmail.com> wrote:
> 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.

Ditto. That is exactly what I do as well.

On Oct 9, 3:24*am, "Jon Skeet [C# MVP]" <sk...@pobox.com> wrote:
> On Oct 9, 9:00*am, Slickuser <slick.us...@gmail.com> wrote:
>
> > I always do * close & dispose.
>
> > It might clear up the memory allocation.
>
> No it won't.
>
> > But if you're inside a
> > private method, it will probably get destroy once you leave that
> > method.
>
> 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

One clarification...both Close and Dispose often do release unmanaged
memory though.

On Oct 9, 2:25*pm, Göran Andersson <gu...@guffa.com> wrote:
> 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.

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 <(E-Mail Removed)> wrote:
> > Do you Close() in a finally block, or just at the end of the normal
> > execution?
>
> I close inside the finally block.

Which means life is as bad as Java, without a using statement

> > 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.
>
> Absent a mandate in the .NET specifications, it's not guaranteed
> behavior.

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.

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>

--
Jon Skeet - <(E-Mail Removed)>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com