From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-06-20 14:44:52
possibly off-topic----------- apologies, if so.
Mayhaps the problem here is caused by an unfortunate interpretation by the
Standards Committee to the "Resumption vs. Termination" (Stroustrup "The
Design and Evolution of C++" section 16.6) arguments during the
standardization process. As an example, Stroustrup ("The C++ Programming
Language Third Edition" section 14.4, last paragraph) says: ''The process
of searching "up through the stack" to find a handler for an exception is
commonly called "stack unwinding." As the call stack is unwound, the
destructors for constructed local objects are invoked.''
Bjarne (and apparently the committee (I wasn't there, can't comment
further)) erred in the assumption that "searching up the stack" and
"unwinding (implying destructors being called)" are the same thing, they
are not. Perhaps in their zeal to make C++ exceptions "Termination" rather
than "Resumtion" model they decided that the stack _should_ be "unwound"
before the exception handler is invoked. Of course "unwinding" the stack
makes "resumption" _impossible_ not simply " resumption violates the standard".
In my opinion, this decision hinders effective debugging so badly that it
should be re-considered (If I knew how to write such a suggestion, I would
certainly so do). I have NO argument with the "termination" semantics, I
object to the "destructors being called up the line" until the appropriate
"catch" is found.
Think how _simple_ it would be to provide a "stack trace" if the stack were
Think of how much information would be available to a modern debugger!!
The implementation can't be _that_ difficult, Microsoft's Structured
Exception Handling does it (it has both resume and termination semantics).
The implementation shouldn't be all that much slower either. One simply
puts a new "frame" on the stack for the exception "handler" and "unwinds
the stack" when it returns.
At Thursday 2002/06/20 05:27, you wrote:
>The immediate need I had was, a low-level function contains an
>assert. I gave the code to an associate, who quickly triggered the
>assertion. I couldn't easily tell where it came from since it could
>have been called on various paths. I would have liked to see a
>traceback showing the path through my code, maybe up to main.
>I personally don't often use exceptions. By default on my environment
>(linux/g++) they provide no information to the user that can be fed
>back to the programmer (other than a core). In most cases the core is
>useless when compiled with high optimization on g++.
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
"There oughta be a law"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk