Debugger not cleaning up

[jehugaleahsa]

Hello:

Has anyone ever noticed that when you stop the debugger that
destructors (Finalize) are not called?

I have some code that is supposed to register for an event on a
database. In order for the code not to leave residual records on the
database, I have to unregister when the code ends.

However, when I hit Stop on the debugger, it appears as though the
clean-up code is never called. I have tied implementing IDisposable
and have written a Destructor.

However, when I looked on the database, the registration rows still
appear. It leads me to believe the destructors and disposal methods
are not called at all!

The oddity of this whole arrangement is that it would seem that code
inside finally blocks do get executed. However, I am managing my
registration with a class, so finally is not an option.

BTW, if the code ends naturally, everything gets cleaned up fine.

Does anyone know why this is happening?

Thanks,
Travis

 

[Marc Gravell]

To all intents and purposes, you are killing the process. *nothing*
can be guaranteed to survive this. Your best bet is to implement
something that periodically detects aborted (inactive) sessions;
additionally, if you only expect one session per client, then starting
a new session could clean-up any existing for that client.

Marc

 

[UL-Tomten]

Has anyone ever noticed that when you stop the debugger that
destructors (Finalize) are not called?

According to the MSDN docs, "The Finalize method [...] might not run
at all". Stopping the debugger is such a situation. Like Marc writes,
it's the equivalent of killing the process. If there was a way to
survive that, we'd all be in trouble.

As all CLI/Fx/C# documentation would have told you, you can never rely
on finalizers to run, and if they do, you have no idea when. Since you
write that you have implemented IDisposable, I suggest you continue
along that path, and follow the example in the MSDN docs for
IDisposable (suppressing the finalizer after disposing, etc).

 

[Guest]

to add to the very good comments above

the name 'debugger' should give you a clue to it's purpose, it is not a test
environment or a code proving ground it is for investigating issues.

I suggest you write a set of unit tests to prove that the dispose method is
being called.

HTH

Ollie Riches

Has anyone ever noticed that when you stop the debugger that
destructors (Finalize) are not called?

According to the MSDN docs, "The Finalize method [...] might not run
at all". Stopping the debugger is such a situation. Like Marc writes,
it's the equivalent of killing the process. If there was a way to
survive that, we'd all be in trouble.

As all CLI/Fx/C# documentation would have told you, you can never rely
on finalizers to run, and if they do, you have no idea when. Since you
write that you have implemented IDisposable, I suggest you continue
along that path, and follow the example in the MSDN docs for
IDisposable (suppressing the finalizer after disposing, etc).

 

[jehugaleahsa]

to add to the very good comments above

the name 'debugger' should give you a clue to it's purpose, it is not a test
environment or a code proving ground it is for investigating issues.

I suggest you write a set of unit tests to prove that the dispose method is
being called.

HTH

Ollie Riches

On Sep 5, 11:28 pm, "(e-mail address removed)" <[email protected]>
wrote:

According to the MSDN docs, "The Finalize method [...] might not run
at all". Stopping the debugger is such a situation. Like Marc writes,
it's the equivalent of killing the process. If there was a way to
survive that, we'd all be in trouble.

As all CLI/Fx/C# documentation would have told you, you can never rely
on finalizers to run, and if they do, you have no idea when. Since you
write that you have implemented IDisposable, I suggest you continue
along that path, and follow the example in the MSDN docs for
IDisposable (suppressing the finalizer after disposing, etc).- Hide quoted text -

- Show quoted text -

I suppose they can't make everyone happy. We here at my work have just
decided to make the records on the database expire sooner in
development than in production.

My only other question then becomes: if an unhandled exception occurs
in my code, will the Dispose method or destructors get called. What is
the difference between the application terminating due to an error and
it terminating in the debugging environment?

Thanks,
Travis

 

[Marc Gravell]

Terminating due to an unhandled error will still track back through
the stack, and should still trigger any *correctly implemented"
Dispose() methods. By *correctly implemented", I mean either "using",
or "try/finally" (typically disposing in the finally).

Generally, coding to IDisposable is a much better option than relying
on finalizers (of which few hard guarantees are made) - but if worried
you could add a GC.WaitForPendingFinalizers() in the final "finally"
around your Main() method (assuming an exe).

Marc

 

[Guest]

to be honest I don't like the sound of the design, what kind of event are you
registering for in the database and what is the problem with leaving the
registration there if the application fails for unknown reason?

Ollie Riches

 

[jehugaleahsa]

to be honest I don't like the sound of the design, what kind of event are you
registering for in the database and what is the problem with leaving the
registration there if the application fails for unknown reason?

Ollie Riches

Unfortunately, I am working with another developer who has been
struggling for the past few weeks. To be quite honest, I am not sure
why the residual records on the database pose a problem.

Essentially, Oracle provides a feature that can notify an application
when a change takes place on a table. It is a fairly new technology
and we have found various bugs while using it. When you register to
recieve notifications about events, Oracle stores a record in a
notification table. The table is used to track back to the machine
that made the request and what was requested. Even knowing this, I am
not sure why expired records are really all that important.

Thanks,
Travis