Boost logo

Boost :

From: John Fuller (jfuller_at_[hidden])
Date: 2004-05-24 08:11:13


I don't know if this is helpful, but in my state machine
implementations I move to the next state on success and on failure
remain in the same state and throw an exception event
event at that state, users are expected to configure the machine
to handle exceptions at each state to transition into error handling
behavior or ignore the error, or whatever.
Events are propagated recursively beginning at the most granular state,
so that
parent state changes are only succeed when substate changes succeed.

On May 24, 2004, at 1:49 AM, Andreas Huber wrote:

> 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? 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?
>
>>> 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.
>
> Ok, but how do you propose should the state machine then be
> terminated? By
> simply not calling the exit actions of still active states?
>
> Regards,
>
> Andreas
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk