 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / C# / September 2007Debugger not cleaning up
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 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 On Sep 5, 11:28 pm, "jehugalea...@gmail.com" <jehugalea...@gmail.com> wrote: > 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). 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, "jehugalea...@gmail.com" <jehugalea...@gmail.com> > wrote: [quoted text clipped - 12 lines] > along that path, and follow the example in the MSDN docs for > IDisposable (suppressing the finalizer after disposing, etc). > to add to the very good comments above ;) > [quoted text clipped - 26 lines] > > - 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 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 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 > Terminating due to an unhandled error will still track back through > the stack, and should still trigger any *correctly implemented" [quoted text clipped - 7 lines] > > Marc > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.