destructor not being called

[Andy Fish]

hi,

i have a class called foo that has a method called ~foo (well it might not
be a method but I'm not worried about the actual semantics here)

from what I can tell this makes it a destructor which means it should get
called when the object is disposed of by the runtime. presumably this
includes when the appdomain exits as well as when the GC needs to run to get
more memory?

however, mine is never being invoked. FWIW this is part of a windows service

anyone know what is happening here? what is the accepted best practice for
having some code run when an object is being disposed of ?

TIA

Andy

 

[Christof Nordiek]

hi,

i have a class called foo that has a method called ~foo (well it might not
be a method but I'm not worried about the actual semantics here)

from what I can tell this makes it a destructor

From C# 2.0 on they are officially called finalizers, no destructors. That's
because their semantic is very different from destructors in C++ (and maybe
other languages).

which means it should get called when the object is disposed of by the
runtime. presumably this includes when the appdomain exits
No,

as well as when the GC needs to run to get more memory?

To be more precise, when the GC has run and detected, that the instance
isn't anymore reachable by code (outside of finallizers):

however, mine is never being invoked. FWIW this is part of a windows
service

Why do you think you have to implement a finalizer here? They should only be
used to cleanup work, wich isn't yet done by the .NET-Runtime, like freeing
os-handles wich your code owns. This doesn't normally occur in applidatoin
code.

Christof

 

[Nicholas Paldino [.NET/C# MVP]]

Andy,

Are you looking for having code run when the object is disposed, or when
the object is collected? Writing code for when the object is being
collected doesn't make sense, since you can't determine when exactly that
is. The only use for it now that is reasonable (and in my opinion,
questionably so) is when resources need to be released because the
programmer didn't do so (which I think is an error in design, if you do not
know the lifetime of your objects which require it).

If you are looking for code to perform actions in a deterministic way,
then you will want to implement the IDisposable interface. Check out the
section of the MSDN documentation titled "Implementing a Dispose Method",
located at:

http://msdn2.microsoft.com/en-us/library/aa720161(VS.71).aspx

 

[John Duval]

hi,

i have a class called foo that has a method called ~foo (well it might not
be a method but I'm not worried about the actual semantics here)

from what I can tell this makes it a destructor which means it should get
called when the object is disposed of by the runtime. presumably this
includes when the appdomain exits as well as when the GC needs to run to get
more memory?

however, mine is never being invoked. FWIW this is part of a windows service

anyone know what is happening here? what is the accepted best practice for
having some code run when an object is being disposed of ?

TIA

Andy

Hi Andy,
A common reason that the finalizer (what you're calling the
destructor) might not be called is that the Dispose( ) method has
called GC.SuppressFinalize(this); -- is that possible in your
situation?

Although it's possible that the finalizer isn't getting called for
another reason, I would check this out first.
John

 

[Andy Fish]

it's just to clear up some temporary files.

I don't really care when it gets called, as long as it gets called at some
point before the application exits.

I've just read the documetnation about finalizers and it seems to me that
this is the right thing for me, since the tempoary file is effectively an
unmanaged object associated with the application. I accept that I could use
the IDisposable convention, but this would require me to keep reference
counts and effectively do my own memory management - I thought that's what
the framework was supposed to do for me.

I just don't understand why the finalizer is not being called when the
application is closed down - surely that's what it is for ?

Andy,

Are you looking for having code run when the object is disposed, or
when the object is collected? Writing code for when the object is being
collected doesn't make sense, since you can't determine when exactly that
is. The only use for it now that is reasonable (and in my opinion,
questionably so) is when resources need to be released because the
programmer didn't do so (which I think is an error in design, if you do
not know the lifetime of your objects which require it).

If you are looking for code to perform actions in a deterministic way,
then you will want to implement the IDisposable interface. Check out the
section of the MSDN documentation titled "Implementing a Dispose Method",
located at:

http://msdn2.microsoft.com/en-us/library/aa720161(VS.71).aspx


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

hi,

i have a class called foo that has a method called ~foo (well it might
not be a method but I'm not worried about the actual semantics here)

from what I can tell this makes it a destructor which means it should get
called when the object is disposed of by the runtime. presumably this
includes when the appdomain exits as well as when the GC needs to run to
get more memory?

however, mine is never being invoked. FWIW this is part of a windows
service

anyone know what is happening here? what is the accepted best practice
for having some code run when an object is being disposed of ?

TIA

Andy

 

[Nicholas Paldino [.NET/C# MVP]]

Andy,

IMO, the IDisposable pattern is better here, since I don't think you
should leave temp files lying around if you don't need them.

You don't have to do any memory management when implementing IDisposable
or keep reference counts. Where do you see that this is the case?

In your case, all you have to do is create a class which will manage the
temp files, and in the Dispose method, delete them.

Then, create an instance of this class, and put it in a using block, and
it will be automatically taken care of when the using block is exited.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

it's just to clear up some temporary files.

I don't really care when it gets called, as long as it gets called at some
point before the application exits.

I've just read the documetnation about finalizers and it seems to me that
this is the right thing for me, since the tempoary file is effectively an
unmanaged object associated with the application. I accept that I could
use the IDisposable convention, but this would require me to keep
reference counts and effectively do my own memory management - I thought
that's what the framework was supposed to do for me.

I just don't understand why the finalizer is not being called when the
application is closed down - surely that's what it is for ?

Andy,

Are you looking for having code run when the object is disposed, or
when the object is collected? Writing code for when the object is being
collected doesn't make sense, since you can't determine when exactly that
is. The only use for it now that is reasonable (and in my opinion,
questionably so) is when resources need to be released because the
programmer didn't do so (which I think is an error in design, if you do
not know the lifetime of your objects which require it).

If you are looking for code to perform actions in a deterministic way,
then you will want to implement the IDisposable interface. Check out the
section of the MSDN documentation titled "Implementing a Dispose Method",
located at:

http://msdn2.microsoft.com/en-us/library/aa720161(VS.71).aspx


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

hi,

i have a class called foo that has a method called ~foo (well it might
not be a method but I'm not worried about the actual semantics here)

from what I can tell this makes it a destructor which means it should
get called when the object is disposed of by the runtime. presumably
this includes when the appdomain exits as well as when the GC needs to
run to get more memory?

however, mine is never being invoked. FWIW this is part of a windows
service

anyone know what is happening here? what is the accepted best practice
for having some code run when an object is being disposed of ?

TIA

Andy

 

[Andy Fish]

when I referred to doing my own memory management, I really meant my own
object lifecycle management

e.g. if there might be several references to the object, I would have to
work out when they were all finished and call the dispose() method (the
"using" construct doesn't do this - it simply calles dispose at the end of
the block even if you might have passed the object to some other class which
has kept a reference to it)

having said that, I think a small apology is needed here. after a protracted
debugging session I have determined that finalizers are indeed called when
the windows service is stopped - my problem was down to the fact that the
log4net logging framework was being finalised before my class, so I couldn't
see the debug messages coming out !!!

Andy,

IMO, the IDisposable pattern is better here, since I don't think you
should leave temp files lying around if you don't need them.

You don't have to do any memory management when implementing
IDisposable or keep reference counts. Where do you see that this is the
case?

In your case, all you have to do is create a class which will manage
the temp files, and in the Dispose method, delete them.

Then, create an instance of this class, and put it in a using block,
and it will be automatically taken care of when the using block is exited.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

it's just to clear up some temporary files.

I don't really care when it gets called, as long as it gets called at
some point before the application exits.

I've just read the documetnation about finalizers and it seems to me that
this is the right thing for me, since the tempoary file is effectively an
unmanaged object associated with the application. I accept that I could
use the IDisposable convention, but this would require me to keep
reference counts and effectively do my own memory management - I thought
that's what the framework was supposed to do for me.

I just don't understand why the finalizer is not being called when the
application is closed down - surely that's what it is for ?

Andy,

Are you looking for having code run when the object is disposed, or
when the object is collected? Writing code for when the object is being
collected doesn't make sense, since you can't determine when exactly
that is. The only use for it now that is reasonable (and in my opinion,
questionably so) is when resources need to be released because the
programmer didn't do so (which I think is an error in design, if you do
not know the lifetime of your objects which require it).

If you are looking for code to perform actions in a deterministic
way, then you will want to implement the IDisposable interface. Check
out the section of the MSDN documentation titled "Implementing a Dispose
Method", located at:

http://msdn2.microsoft.com/en-us/library/aa720161(VS.71).aspx


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

hi,

i have a class called foo that has a method called ~foo (well it might
not be a method but I'm not worried about the actual semantics here)

from what I can tell this makes it a destructor which means it should
get called when the object is disposed of by the runtime. presumably
this includes when the appdomain exits as well as when the GC needs to
run to get more memory?

however, mine is never being invoked. FWIW this is part of a windows
service

anyone know what is happening here? what is the accepted best practice
for having some code run when an object is being disposed of ?

TIA

Andy

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

it's just to clear up some temporary files.

I don't really care when it gets called, as long as it gets called at some
point before the application exits.

I've just read the documetnation about finalizers and it seems to me that
this is the right thing for me, since the tempoary file is effectively an
unmanaged object associated with the application. I accept that I could use
the IDisposable convention, but this would require me to keep reference
counts and effectively do my own memory management - I thought that's what
the framework was supposed to do for me.

I just don't understand why the finalizer is not being called when the
application is closed down - surely that's what it is for ?

You should use the Disposable pattern if you want to be sure that the
files are removed.

The finalizer is executed in most cases, but it's not guaranteed to be
executed. If the finalizer queue takes too long to run through when the
application ends, the system will just cut the losses and throw the rest
of the objects away.