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

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-05-28 12:03:53

----- Original Message ----- 
From: "Rob Stewart" <stewart_at_[hidden]>
> 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:

I don't understant what you mean by "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?

I don't think that it is a slight difference. If you make an assumption
that all unhandled exceptions will eventually trigger
stack unwinding, but a specific implementation doesn't do that,
it is huge difference.
Such an implementation (legal implementation, btw) may break
a bunch of RAII based designs.

> Why would this -- no stack unwinding for an unhandled exception
> -- matter in boost::fsm?

Because boost::fsm doesn't allow me to discriminate
exception types and keep the stack from unwinding
(for unhandled exceptions) at the same time.

> Put another way, what benefit does this
> provide and does it outweight the benefits of the approach being
> used now?

Sorry, what outweighs what?

Eugene