begin quoting Christopher Smith as of Tue, Jan 15, 2008 at 11:19:57PM -0800: > SJS wrote: > >An exception in a destructor was one of the most annoying bugs I ever > >had to track down in C++ -- everything was kosher and groovy at the > >return, but the function never returned. > > > >Didn't take long to narrow down the problem to the particular return. > >I eventually found it by single-stepping the debugger, after loading > >all of the support library code source I could lay my hands on into > >the project's environment. > > Actually, that's not the problem with exceptions in destructors (and if > anything it is easier to deal with than GC's or finalizers tripping over > themselves at random...
Y'know, I've not seen that at all. Probably because I don't much care for retrofitted GCs. Build it into the language, or leave it out. Anything else is asking for trouble. :-/ > we had a top Digitalk guy work with us for over > a month tracking down what proved to be a simple misunderstanding in how > OS/2's resource management worked). Even if it were, I'd ask why you > didn't have a stack trace from the exception that quickly identified > what was happening. Seems odd. What stack trace? This was C++. I couldn't find anything about getting a stack trace from an exception in any of the books on the shelf that I had access to, nor did I have any luck on the web. If there is a way to obtain a stack trace from a thrown integer, *please* tell me! An exception without a stack trace is useless. > No, the problem with exceptions being thrown in destructors is what > happens if the destructor itself is being triggered by a different > exception that is unwinding the stack. Um, no, that's _another_ problem. An exception in a destructor is a problem as soon as it shows up in your support code. Sure, it's easy enough if _my_ class has the problem, but if it's in a class that's used by a class that's used by a support library that's used by another support library that's used by a class that you're using in the class you wrote, well, it's quite the headache. > It generally only comes up as a > big problem if you are aggressively doing generic programming, and > fortunately the runtime bombs in rather clear and explicit ways, which > makes it easy to diagnose. "SEGFAULT" is not terribly clear nor explicit. -- The plural of an acronym should not involve an apostrophe, The person who first removed it deserves a shiny trophy. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
