Re: [boost] Re: improved assertions?

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-06-21 09:41:19

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

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

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 (and that local variables
could not be referred to anyway by lack of static information about them).

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