Boost logo

Boost :

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.
>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
> }

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.
>Unsubscribe & other changes:

Victor A. Wagner Jr.
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, gregod at, cpdaniel at, john at