Re: [boost] Re: improved assertions?

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-06-21 16:58:53

At Friday 2002/06/21 07:41, you wrote:

>----- Original Message -----
>From: "Victor A. Wagner, Jr." <vawjr_at_[hidden]>
>To: <boost_at_[hidden]>
>Sent: Thursday, June 20, 2002 7:19 PM
>Subject: Re: [boost] Re: improved assertions?
>
>
> > rely on unwinding _before_ the catch handler executes??
>Yes, or at least, as the first event that ocurrs within the catch handler.
>Consider:
>
>void foo()
>{
>   std:auto_ptr<thing> resource(new thing);
>   throw 0 ;
>}
>
>void bar()
>{
>   try
>  {
>    foo();
>  }
>  catch ( int const& )
>  {
>    // At this point, the stack has been unwinded already, thus I know that
>'resource' from within foo()
>    // is already deleted.
>    // I could call exit(..) here without a leak (from what's done within the
>try-block).
>  }
>}

Are you suggesting that calling exit() doesn't finish unwinding the stack 
when it's finished?
That seems to me to make it impossible to write a program which doesn't 
"leak" if ANY call to exit() exists.

> > I didn't suggest within the throwing frame, I suggested a new frame (the
> > catch LOOKS almost like a function anyhow)..... catch (const
> > std::exception& except){body}
>
>But were would this new frame be? frames are always within frames in the C++
>execution model.

Sorry, I mis-interpreted you use of "within".. I really did mean make throw 
appear to be a call to function (create a new frame and all).

>Currently, the catch handler 'frame' is coincident with the try-block frame.
>The throwing frame is necessarily nested, so the only way by which a catch
>handler could access the throwing frame (which is essentially what we're
>looking for) is to be located within the throwing frame. It could be nested
>in the throwing frame if C++ used extended scopes, but even then it would be
>within the throwing frame.

I wasn't referring to "access"ing the throwing frame in the normal sense 
(changing the local variables, etc.) ...only to be _able_ to write a "stack 
call trace" (unique for every implementation, I suspect) to get some 
debugging information.

>It is precisely the fact that the catch handler doesn't execute within the
>throwing frame that makes it pretty useless (as David pointed out), since
>what happened that thrown is already in 'the past'. I thought that you
>considered that catch handlers could execute within the throwing frame since
>then all the information would be there. This would have been possible
>provided that after the handler, the stack is unwinded up to the end of the
>try block (jus as it is now); but this would imply that local objects are
>not destructed by the time the handler executes

not a problem, from my point of view...unless exit() really IS something 
other than I thought.

>(and that local variables
>could not be referred to anyway by lack of static information about them).

yes, there wouldn't be any local variables {other than those declared 
inside the catch block} to play with.
..... I _told_ them they'd ultimately regret keeping it lexically flat 
..... --- Blaise Pascal

>Fernando Cacciola
>Sierra s.r.l.
>fcacciola_at_[hidden]
>www.gosierra.com
>
>
>
>_______________________________________________
>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"