GC.SuppressFinalize()

  • Thread starter Thread starter Lloyd Dupont
  • Start date Start date
L

Lloyd Dupont

I used FxCop on my assembly recenlty, ouch...

There is one statement I wonder about (in fact there is many, but let's
start wit this one)

I have a Dispose() method and it advice me to call
GC.SuppressFinalize() method me.
I don't want as I use no finally (I haven't implemented any destructor), my
class being fully managed don't require them, but I do use stuff like Brush,
etc ... so I have a Dispose() method.

Am I right ?
Isn't GC.SuppressFinalize() of any use only if there is a destructor (a
~MyObject() method) ?
 
You are correct: without a destructor (finalize method), you won't be on the
finalize queue anyways, so calling SuppressFinalize shouldn't do anything.
I'm interested in seeing what the FxCop rule says in more detail though. I'm
guessing it's just to keep things following the design pattern (since many
Disposable objects are finalizable).

-mike
MVP
 
Hey Michael,

Are you sure about this? All types have a finalizer through Object.Finalize. Are you saying that obejcts are only placed in the finalize queue if their type overrides Object.Finalize?

Regards, Jakob.
 
Jakob Christensen said:
Are you sure about this? All types have a finalizer through
Object.Finalize. Are you saying that obejcts are only placed in the
finalize queue if their type overrides Object.Finalize?
Click to expand...

Yes, thank goodness - otherwise all objects would survive one more
garbage collection than they need.
 
I thought one of the purposes of Finalize was to clean up those resources
(Brush, etc.) in the case that your Dispose is not called. Haven't you set
yourself up for leaks without a finalizer?
 
Daniel Billingsley said:
I thought one of the purposes of Finalize was to clean up those resources
(Brush, etc.) in the case that your Dispose is not called. Haven't you set
yourself up for leaks without a finalizer?
Click to expand...

No - his class is fully managed, it just presumably wraps other things
which need disposal, which may themselves have finalizers.

Take StreamWriter, for instance. It has a Dispose method which it
proxies onto the stream in question, but there's no point in it having
a finalizer, because the stream itself will.
 
Glad I was right and thanks for all your answers.
It tooks me a while to understand what's going on during object collection,
so I'm happy I get it right.


there is another things which puzzle me with FxCop, it advices me to set the
ComVisibleAttribute false on my assembly and true on each type.

Well I hate COM (mainly out of ignorance of something which appears to me
exagerately complex for no particular result), anyway I don't see why FxCop
is bothering with a technology of a past I don't care about.

Beside having no idea what it is I don't see the point in choosing on a per
class basis wether or not I set the 'ComVisible' attribute to true and would
rather set it true on the whole assembly or turn off the rule...
 
If you are not using/caring about COM, you can disable those rules in FxCop.
-mike
MVP
 
Ah, that makes sense since the Finalizer is just a failsafe. It would be
important to verify that "may" part for each thing wrapped, wouldn't it?

Can you give a common example of a class you would write that would itself
be an unmanaged resource and not just a wrapper?
 
Daniel Billingsley said:
Ah, that makes sense since the Finalizer is just a failsafe. It would be
important to verify that "may" part for each thing wrapped, wouldn't it?
Click to expand...

Well, if you're using a class that itself is unreliable, you're only
adding one extra layer - it would fail if people used it directly and
didn't call Dispose, and you're adding a layer which means it will
still fail if people use the wrapper and don't call Dispose. I
personally wouldn't worry about it.
Can you give a common example of a class you would write that would itself
be an unmanaged resource and not just a wrapper?
Click to expand...

Anything that contains an unmanaged handle. For instance, in the
Compact Framework there aren't any registry classes - so you need to
write your own (or use the OpenNETCF one :) which will contain a handle
directly.
 
Very true once again.

And since you can't reference objects in your finalizer by that point it's
pretty hopeless in trying to do much more than that isn't it?
 
Daniel Billingsley said:
Very true once again.

And since you can't reference objects in your finalizer by that point it's
pretty hopeless in trying to do much more than that isn't it?
Click to expand...

Well, you *can* reference objects in your finalizer - it's just a bad
idea, because they may already have been finalized. (And in another
version of the CLR, they may be in the process of being finalized on
another thread - now there's a scary thought!)
 
Yeah that's what I meant. I was originally going to reply that at least it
would be better to Dispose those other known objects in your finalizer
rather than just say the heck with it and let their finalizer eventually
run, but I it would be bad form to do so for the reasons you state. That's
what I meant in saying by the time you hit your finalizer you have to just
accept things have gone awry.
 
Back
Top