"Andreas Huber" <ah2003@[...].net>  writes:

>  David Abrahams wrote:
> > "Andreas Huber" <ah2003@[...].net> writes:
> >
> >> I don't think I have missed your point and I know that I'm talking
> >> to an exception handling expert. Have you read that whole paragraph?
> >
> > Yep
> >
> >> Agreed, after
> >> posting I noticed that the first half isn't exactly the best
> >> explanation of why exit actions must not fail. However, I believe
> >> that the second half is a good argument why throwing exit actions
> >> are a bad idea: <quote>
> >> ... However, even if exit actions are called in the
> >> course of a normal transition what are you going to do if B's exit
> >> action throws an exception?
> >
> > Stay at B, of course (?)
> >
> >> Technically, the state machine still resides in B, so
> >> you have pretty few options for continuing. You cannot exit A as
> >> that would violate the state machine invariant that inner states are
> >> always exited before outer states. You cannot make a transition to
> >> another state, as that would also require successful exit from B.
> >> So, the only sensible thing is to try to handle the error inside B's
> >> exit action.
> >
> > I don't understand why.  The user of the FSM could handle the
> > exception on the outside if its state doesn't change.
> 
>  Ok, I seem to finally see your point. You would want to leave the state
>  machine in a possibly *invalid* state when propagating the exception to the
>  state machine client, right? 

No.  I said it should stay in the same state it was already in.
Presumably the exit action is the first thing that would happen on a
transition (?), so if it fails, you haven't gone anywhere and the
machine should still be in a valid state.

>  So what is the user then doing with the state
>  machine object after handling that exception? Since the machine might be
>  unstable he cannot process any more events. What's even more disturbing is
>  the fact that he cannot even successfully destroy the state machine. Or are
>  you proposing that the exit actions of the still active states should not be
>  called upon destruction?

I am proposing that.  Leaving a state via transition seems
fundamentally different from what must happen when you're simply done
using a state machine and it is destroyed.

> > that sounds like it could be the wrong design decision, to me.
> 
>  Ok, but how do you propose should the state machine then be terminated? By
>  simply not calling the exit actions of still active states?

Yes, why not?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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