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;