"Andreas Huber" <ah2003@gmx.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.
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 client.
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