From: David Abrahams (dave_at_[hidden])
Date: 2004-05-23 20:05:55
"Andreas Huber" <ah2003_at_[hidden]> 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?
> 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:
> ... 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.
> If the error cannot be handled there it must either be ignored or,
> in the case of a really serious error, be handled with a different
> mechanism than exceptions. </quote>
> A maybe more convincing argument:
> In the course of a transition a state entry action throws an exception. Note
> that the state machine is in an invalid state (unstable) when this happens.
> If the state machine does not successfully handle the exception, the
> exception must be propagated to the state machine client. Because the state
> machine is unstable, it *must* be terminated before propagating to the
OK so far...
> Termination calls the exit actions of all currently active states.
that sounds like it could be the wrong design decision, to me.
> What are you going to do with exceptions thrown by these exit actions?
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk