Dispose and Finalize hell!

[BLUE]

I've read many articles including the one from Duff's blog but I've many
doubts.
public static myClass Instance
{
get
{
if (myClass.instan ce == null)
myClass.instanc e = new myClass();

if(myClass.inst ance.disposed)
throw new ObjectDisposedE xception(myClas s.objectName);

return myClass.instanc e;
}
}

This is Singleton Instance property: it is right to throw that exception or
I must create a new object if the previous was disposed?
I know that if class A has unmanaged fields, like an IntPtr, it should
implement Dispose pattern (Dispose+Finali ze = D+F)

I have:
- a class A that implements D+F
- a class B that has a field objA (of type A)
- a class C that contains Main (in a console app) or that is the main form
and has a field objB (of type B)

I think B should implement only Dispose (IDisposable) so that C can free
resources when it does not need them anymore.

I don't know why B should implement a Finalize method: if C doesn't remember
to call objB.Dispose GC will call objA.Finalize and I don't see any benefit
in implementing Finalize in B because it will be called in a non
deterministic way as for objA.Finalize!
(If I have N classes and class I use class I+1 I do not want to implement N
couples of D+F if I don't need to since Finalize has a cost.)

Moreover I think C have not to implement D or D+F: Dispose is a method to be
called by the user of a class to free unused resources, so who calls the
Dispose of the class that start the application???
Thank you all!
Luigi.

[=?ISO-8859-1?Q?Lasse_V=E5gs=E6ther_Karlsen?=]

BLUE wrote:

I've read many articles including the one from Duff's blog but I've many
doubts.
public static myClass Instance
{
get
{
if (myClass.instan ce == null)
myClass.instanc e = new myClass();

if(myClass.inst ance.disposed)
throw new ObjectDisposedE xception(myClas s.objectName);

return myClass.instanc e;
}
}

This is Singleton Instance property: it is right to throw that exception or
I must create a new object if the previous was disposed?
I know that if class A has unmanaged fields, like an IntPtr, it should
implement Dispose pattern (Dispose+Finali ze = D+F)

I have:
- a class A that implements D+F
- a class B that has a field objA (of type A)
- a class C that contains Main (in a console app) or that is the main form
and has a field objB (of type B)

I think B should implement only Dispose (IDisposable) so that C can free
resources when it does not need them anymore.

I don't know why B should implement a Finalize method: if C doesn't remember
to call objB.Dispose GC will call objA.Finalize and I don't see any benefit
in implementing Finalize in B because it will be called in a non
deterministic way as for objA.Finalize!
(If I have N classes and class I use class I+1 I do not want to implement N
couples of D+F if I don't need to since Finalize has a cost.)

Moreover I think C have not to implement D or D+F: Dispose is a method to be
called by the user of a class to free unused resources, so who calls the
Dispose of the class that start the application???
Thank you all!
Luigi.

You only implement finalizers on objects that contain unmanaged
resources, like that IntPtr.

In your example, I would gather only objA should have a finalizer.

The rest should have IDisposable support though so you can do a
deterministic cleanup when needed.

In the "class that start the application", Main() is static, so there
won't be an instance of this class in play, unless your program
constructs one on its own, so no, this class does not need finalizer nor
IDisposable.

--
Lasse Vågsæther Karlsen
mailto:la***@vk arlsen.no

[Laura T.]

Something I've learned:

1. Think as there would not be Finalization system
Finalization is an anomaly of the system. An error. Should never happen.

2. Implementing IDisposable is never an error
It might do nothing useful for now, but maybe later the class grows to
manage resources that are worth of eliminating.
If all callers dispose you, you have more freedom to modify the class.
So implement IDisposable in every class and be happy.

3. Only the direct owner of the non managed resource must implement
finalizer
The rule 1 is good, but we are still humans. Just in case someone omits
Dispose. We want a safe system, after all.
In debug builds, throw Assert in finalizer to let the world know and to
catch the missing Dispose().
"BLUE" <blueha scritto nel messaggio
news:eW******** ******@TK2MSFTN GP04.phx.gbl...

I've read many articles including the one from Duff's blog but I've many
doubts.
public static myClass Instance
{
get
{
if (myClass.instan ce == null)
myClass.instanc e = new myClass();

if(myClass.inst ance.disposed)
throw new ObjectDisposedE xception(myClas s.objectName);

return myClass.instanc e;
}
}

This is Singleton Instance property: it is right to throw that exception
or I must create a new object if the previous was disposed?
I know that if class A has unmanaged fields, like an IntPtr, it should
implement Dispose pattern (Dispose+Finali ze = D+F)

I have:
- a class A that implements D+F
- a class B that has a field objA (of type A)
- a class C that contains Main (in a console app) or that is the main form
and has a field objB (of type B)

I think B should implement only Dispose (IDisposable) so that C can free
resources when it does not need them anymore.

I don't know why B should implement a Finalize method: if C doesn't
remember to call objB.Dispose GC will call objA.Finalize and I don't see
any benefit in implementing Finalize in B because it will be called in a
non deterministic way as for objA.Finalize!
(If I have N classes and class I use class I+1 I do not want to implement
N couples of D+F if I don't need to since Finalize has a cost.)

Moreover I think C have not to implement D or D+F: Dispose is a method to
be called by the user of a class to free unused resources, so who calls
the Dispose of the class that start the application???
Thank you all!
Luigi.

[Jon Skeet [C# MVP]]

Laura T. <la*******@yaho o.comwrote:

2. Implementing IDisposable is never an error
It might do nothing useful for now, but maybe later the class grows to
manage resources that are worth of eliminating.
If all callers dispose you, you have more freedom to modify the class.
So implement IDisposable in every class and be happy.

I completely disagree with this. If you implement IDisposable for
*every* type you write, then everything using that type must have a
very concrete idea about the "owner" of every single instance. That
effectively gets rid of all the benefits of garbage collection, because
where you would call free() (or whatever) in a non-garbage-collected
environment, you now call Dispose.

There are some classes where it makes sense to implement IDisposable
even when you don't need it yet, but most of the time there's *very*
little chance that you'll ever need it.

Implementing IDisposable makes life harder for clients. Why make
*everyone's* life harder just on the off-chance that you might have to
make *someone's* life harder at some point in the future?

(I can only think of a *very* few situations where I've gone back and
implemented IDisposable after the fact. Certainly in less than 1% of
the types I've written.)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jesse Houwing]

Laura T. <la*******@yaho o.comwrote:

>2. Implementing IDisposable is never an error
It might do nothing useful for now, but maybe later the class grows to
manage resources that are worth of eliminating.
If all callers dispose you, you have more freedom to modify the class.
So implement IDisposable in every class and be happy.

<snip>

* Jon Skeet [C# MVP] wrote, On 17-5-2007 20:06:

(I can only think of a *very* few situations where I've gone back and
implemented IDisposable after the fact. Certainly in less than 1% of
the types I've written.)

And if you need to do it, Create a new type and either inherit from the
old one, and add IDisposable. If need be, mark the old type abstract.

Or mark the old type Obsolete and copy the original contents to a
completely new type.

There currently are no ways to make sure you've called Dispose on a
Disposable object, so if someone adds it at a later time, it should be
something that comes up at compile time. The Above mentioned cases do that

Jesse