From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-05-28 10:45:24
--- Andreas Huber <ah2003_at_[hidden]> 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