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 transitions.
In your watch sample, is the Active state is innermost common outer state of the Stopped and Running states?
Yes.
Are the Stopped and Running states are "innermost" states?
Yes.
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 know 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 to?
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. Regards, Andreas