Call Dispose in a method?

  • Thread starter Thread starter wobbles
  • Start date Start date
W

wobbles

Hi Everyone,

I've read most of the posts regarding "Dispose" in this NG.
I still have some questions.

If I declare and use a disposable object (say a DB connection) within
a method, is it worth calling Dispose() within my "finally" block,
even if that object only has local scope?

When the thread exits this method, won't the GC collect my disposable
object regardless of whether I call Dispose() or not?

What would be the difference between calling Dispose() here and not
calling Dispose()?

Thanks for clearing my confusion...
Wobbles
 
wobbles said:
I've read most of the posts regarding "Dispose" in this NG.
I still have some questions.

If I declare and use a disposable object (say a DB connection) within
a method, is it worth calling Dispose() within my "finally" block,
even if that object only has local scope?
Click to expand...

Absolutely - although I'd use a using() block.
When the thread exits this method, won't the GC collect my disposable
object regardless of whether I call Dispose() or not?
Click to expand...

No. The GC doesn't run at the end of every method - it runs when it
feels it needs to.
What would be the difference between calling Dispose() here and not
calling Dispose()?
Click to expand...

Timing - if you call Dispose(), all the appropriate cleaning up will be
done by the time the call returns, rather than at some indeterminate
point in the future.
 
Disposable objects are objects that typicall use resources that the GC is
slow to reclaim or may not reclaim at all. By calling Dispose() you let
the object know that it should release it's resources. It will do so, and
wait to be eaten by GC.

If you don't call Dispose() you run the risk of running out of resources
(GC isn't very good at cleaning up those).
 
wobbles said:
If I declare and use a disposable object (say a DB connection) within
a method, is it worth calling Dispose() within my "finally" block,
even if that object only has local scope?
Click to expand...

Yes. You should ALWAYS call Dispose if you do not need this object anymore.

When the thread exits this method, won't the GC collect my disposable
object regardless of whether I call Dispose() or not?
Click to expand...

GC only calls finalizers, not Dipose()...

The object should implement a finilizer if this situation is allowed.
Some objects have the IDisposable-Interface but they are not implemeting a
Finalizer.

So if you do not call Dispose the resourse will never be freed (maybe at
program termination)


--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp
 
And the finallizer normally calls dispose (except not the unmanaged path if
you follow the normal pattern for IDisposable)
 
Absolutely - although I'd use a using() block.
Click to expand...

I understand that the "using()" block replaces "try" and "finally" but
how do I implement a catch to handle exceptions when I use "using"?
No. The GC doesn't run at the end of every method - it runs when it
feels it needs to.
Click to expand...

Ah, I wasn't sure about this. Thanks for clearing it up.
I thought that exiting the method would be a trigger for the GC.
Obviously not.
Timing - if you call Dispose(), all the appropriate cleaning up will be
done by the time the call returns, rather than at some indeterminate
point in the future.
Click to expand...

Thanks Jon.
 
Thanks for answering my questions. I've read all replies and they've all been
useful.

I have one more question:

I had thought of implementing the IDisposable interface in my class but there
are no class-level variables that need disposing. I only have declarations of
references to disposable objects within methods.

Should I implement IDisposable? *What* would I dispose when I override Dispose()
(considering my disposable object is in a method)?



Say I have:

public class Wobbles {

public Wobbles {}

public void DoThings() {
DisposableObject o = null;
try {
o = new DisposableObject();
o.Dosomething();
}catch (Exception e) {
//catch exceptions
}finally {
if (o!=null) o.Dispose();
}
}
}
 
wobbles said:
I understand that the "using()" block replaces "try" and "finally" but
how do I implement a catch to handle exceptions when I use "using"?
Click to expand...

I would personally either wrap the using block in a try/catch, or wrap
the try/catch in a using block. I'd prefer that to doing the finally
block explicitly, just for easy maintenance.

<snip>
 
wobbles,

If you need to catch exceptions, then in this case, do not use "using".
Use a try/catch/finally block and make sure you declare your variables
outside of the block and initialized to null (initialize in the block).

Hope this helps.
 
Nicholas Paldino said:
If you need to catch exceptions, then in this case, do not use "using".
Use a try/catch/finally block and make sure you declare your variables
outside of the block and initialized to null (initialize in the block).
Click to expand...

I don't like doing that as it "pollutes" the variable namespace. I'd
rather use:

try
{
using (...)
{
}
}
catch (...)
{
}

or

using (...)
{
try
{
}
catch (...)
}

personally. It's then easier to make sure you're cleaning things up,
'cos you only need to check that your using block is there.

Just personal preference though.
 
wobbles said:
Thanks for answering my questions. I've read all replies and they've all been
useful.

I have one more question:

I had thought of implementing the IDisposable interface in my class but there
are no class-level variables that need disposing. I only have declarations of
references to disposable objects within methods.
Click to expand...

In that case you don't need to implement it. You should only implement
it if you've really got something to do.
 
If you need to catch exceptions, then in this case, do not use "using".
Use a try/catch/finally block and make sure you declare your variables
outside of the block and initialized to null (initialize in the block).

Hope this helps.
Click to expand...

This is what I currently do but I've been interested in using "using" because it
does seem cleaner.

I've just seen Jon's follow-up post.
I'll try this for a while and see how I get on with it.
 
wrote:
And the finallizer normally calls dispose (except not the unmanaged
path if you follow the normal pattern for IDisposable)
Click to expand...

If you implement the pattern correctly you need the following:

<code>
public class Test : IDisposable
{
~Test()
{
Dispose(false);
}

void IDisposable.Dispose()
{
Dispose(true);
GC.SuppressFinilize(this);
}

private void Dispose(bool disposing)
{
// do some stuff...
}
}
</code>

--
Greetings
Jochen

Do you need a memory-leak finder ?
http://www.codeproject.com/tools/leakfinder.asp
 
I think the private Dispose(bool Disposing) method should be protected
virtual, unless your class is sealed.
 
Back
Top