From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-28 07:31:40
E. Gladyshev <eegg <at> comcast.net> writes:
> > No, the term is "innermost common outer state", not "innermost state". The
> > innermost common outer state is only defined during a transition and is
> > exactly the same as the LCA, see definitions.html.
> The definition of "innermost common outer state" is
> "The innermost common outer state of two states is the first direct or
> indirect outer state that
> both states have in common".
> It doesn't say anything about transitions?
Sorry for the confusion. Yes, it is defined for any two states in your state
chart. What I wanted to say is that it has little meaning outside of
> In your watch sample, is the Active state is innermost common outer state
> of the Stopped and Running states?
> Are the Stopped and Running states are "innermost" states?
> My concernt is that your exception handing model has this internal
> if/else mechanism.
> "If the state machine is stable when the exception is thrown, the state that
> caused the exception
> is first tried for a reaction. Otherwise the outermost unstable state is
> first tried for a reaction."
> How do I incorporate this if/else behavior in my traditional state machine
> design process?
The idea behind this if/else mechanism is that the event resulting from the
exception is always sent to exactly the state from where a full recovery is
possible. If an in-state reaction throws, then obviously the machine is stable
and the exception_event can be processed by the state that caused the
exception. For failing entry actions this is impossible so from the point
where the exception actually happened the dispatcher moves outward until it
finds a state that *could* bring the state machine back into a stable state
(by a transitioning to an other state or by terminating).
> For instance if I add an exception_thrown reaction to a state, how will I
> whether this reaction is called as the result of an exception that occured
> in this state or in one of its inner states?
> How can I tell whether it is a failed react function failed entry action
> of failed transition?
I assume you mean that you cannot distinguish between failing in-state
reactions of the outer state, failing entry actions of the inner states and
failing transition actions between the inner states. That is true. I have
never though about this. Is that a problem for you?
> > Well, since the state machine is terminated when you fail to handle the
> > exception_thrown event, you could argue that the exception handling system
> > does add one reaction (the termination). Is that what you are referring
> Yes, plus those implicit transitions that depend on where the
> exception is thrown (react/entry action/transition)?
Those aren't transitions, are they? The *reaction search* algorithm just acts
differently in the face of failure. If it wouldn't, it is possible that your
state machine is left in an invalid state when you make a mistake while
handling the exception_thrown event.
> It seems to me that with your exception handling process,
> the well established state machine design techniques will need
> to be revisited. I am not saying that it
> is a bad thing, it just needs some theoretical work.
I believe that the current way of handling exceptions in boost::fsm is not far
away from what you can possibly hope for. However, I agree that I'll need to
justify it much more thoroughly. As I mentioned before I will update the
Rationale (as soon as this thread has died down).
> Like you mentioned before, all the FSM theories
> aren't addressing the exception handling stuff.
> You are suggesting a practical solution but a good
> theory is absent.
True. I hope some of the rationale I will write can establish that theory.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk