"Andreas Huber" <ah2003@gmx.net> writes:
David Abrahams wrote:
"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.
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