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

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-24 03:28:47

"Andreas Huber" <ah2003_at_[hidden]> writes:

> David Abrahams wrote:
>> "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?
>>
>> 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