--- Andreas Huber <ah2003@[...].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

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