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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost