Boost logo

Boost :

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-05-28 10:45:24

--- Andreas Huber <ah2003_at_[hidden]> wrote:
> E. Gladyshev <eegg <at>> writes:

> The idea behind this if/else mechanism is that the event resulting from
> exception is always sent to exactly the state from where a full recovery
> possible. If an in-state reaction throws, then obviously the machine is
> 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
> finds a state that *could* bring the state machine back into a stable
> (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
> > know
> > whether this reaction is called as the result of an exception that
> > 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
> 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
> > > exception_thrown event, you could argue that the exception handling
> > > does add one reaction (the termination). Is that what you are
> > 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
> 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...


Boost list run by bdawes at, gregod at, cpdaniel at, john at