Re: [boost] Re: [prereview request][fsm]

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-28 11:35:10

From: "E. Gladyshev" <eegg_at_[hidden]>
> --- Rob Stewart <stewart_at_[hidden]> wrote:
> > From: "E. Gladyshev" <eegg_at_[hidden]>
> 
> > > try{...}
> > > catch(...)
> > > {
> > > try { throw; }
> > > catch( type1 ) { ... }
> > > }
> > >
> > > is very different from
> > >
> > > try{...}
> > > catch( type1 ) {...}
> 
> [...]
> 
> > IOW, stack unwinding will occur for
> > both forms, it's just a question as to where the handler will be
> > found.
> 
> 15.5.1/2
>     Note: in the situation where
>     no matching handler is found, it is implementation-defined whether  or
>     not  the  stack is unwound before terminate() is called.  In all other
>     situations, the stack shall  not  be  unwound  before  terminate()  is
>     called
> 
> Your claim that the stack unwinding will occur in both cases
> is based on an implementation-defined behavior. In fact,
> all implementations that I know about allows you disable
> the stack unwinding for unhandled exceptions.
> So it is not strictly portable nor generic.

That's non-normative text, but it turns out that 15.3/9 covers
it:

   If no matching handler is found in a program, the function
   terminate() is called; whether or not the stack is unwound
   before this call to terminate() is implementationdefined
   (15.5.1).

So, OK, there is that slight difference, but why would you care?
Why would this -- no stack unwinding for an unhandled exception
-- matter in boost::fsm?  Put another way, what benefit does this
provide and does it outweight the benefits of the approach being
used now?

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;