--- Andreas Huber <ah2003@gmx.net> wrote:
E. Gladyshev <eegg <at> comcast.net> writes: [...]
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).
Right. So the process of bringing the state machine back into a stable state is not explicitly defined by the designer. Right? This is what I meant when I said that in this case, the determinism of the traditional state machines is gone.
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.
That is exactly what I mean.
I have never though about this. Is that a problem for you?
I don't know yet. Like I said I am not yet sure how to use your exception handling in practice but it seems like it is changing the traditional approach to the state machine design process. One suggestion that I have is this. Perhaps before the suggested exception handling is fully researched, boost::fsm should follow the well established standards by default and have the new exception handling as a predefined policy that user would have to select explicitly and not the other way around?
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?
Right. Sorry. I should have said the reaction selection process. [...]
I believe that the current way of handling exceptions in boost::fsm is not
far
away from what you can possibly hope for.
No, it is not far. I personally cannot think of anything better.
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.
It'd be great. I believe that it should be more like an academic research. Perhaps you might consider producing an academic paper on this subject... Best, Eugene