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

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-05-28 13:03:03

From: "E. Gladyshev" <eegg_at_[hidden]>
> From: "Rob Stewart" <stewart_at_[hidden]>
> > >
> > > 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).

15.3/9 is normative text and, as quoted here, clearly states that
stack unwinding may not be done before calling terminate().

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

Why would you want the non-deterministic behavior?

> Such an implementation (legal implementation, btw) may break
> a bunch of RAII based designs.

Well, that may be a problem in the specification of the language
that should be addressed.  After all, RAII is generally the
preferred solution for writing exception tolerant code.  Perhaps
Dave Abrahams can weigh in on this.

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

Why would you want terminate() to be called without stack
unwinding on those platforms that do it?  What does that get you?
I would think that boost::fsm's behavior, being more
deterministic, would be preferable.

> > Put another way, what benefit does this
> > provide and does it outweight the benefits of the approach being
                        ^^^^^^^^^
Man I've got to stop my brain from adding that extra "t!"

> > used now?
> 
> Sorry, what outweighs what?

Does not unwinding the stack when terminate() is called, on
whatever platforms do that, gain you something that outweighs the
determinism and reuse of the boost::fsm approach?

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