----- Original Message ----- 
From: "Rob Stewart" <stewart@[...].com> 
>  From: "E. Gladyshev" <eegg@[...].net>
>  > --- Rob Stewart <stewart@[...].com> wrote:
>  > > From: "E. Gladyshev" <eegg@[...].net>
>  >
>  > > > 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost