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... 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.
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. 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.
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
