Re: [boost] Re: improved assertions?

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-20 16:39:39

----- Original Message -----
From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, June 20, 2002 4:44 PM
Subject: Re: [boost] Re: improved assertions?

> 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
> still intact!!
> 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.
>
Maybe. But is anyway too late for this; there are already many idioms
relying on stack unwinding, such as RAII.
It would break a lot of code -and a lot of thinking- if catch handlers
executed from within the frame were the exception was thrown.
I admit that not being able to access the throwing frame is a pain in the
...and terminating the application just to take a snapshot of it is a though
call -and for some of us not even an option-.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com