From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-05-27 11:32:26
--- Andreas Huber <ah2003_at_[hidden]> wrote:
> E. Gladyshev <eegg <at> comcast.net> writes:
> > If the entry or exit action throws, the state machine is in undefined
> > state...
> > unless you define the throw event as a legitimate event
> > which causes a transition. However I don't see how
> > this can be done generically.
> boost::fsm does exactly this and in a generic fashion.
Does it mean that the state machine framework allows
me to specify what event it will generate
for a particular exception type?
If so does it mean that all unspecified exceptions
won't be caught by the framework?
> > In our project, we decided:
> > 1. The state machine *framework* never catches user exceptions.
> > 2. The framework doesn't have a concept of failed actions at all.
> > Any action has to be completed.
> This is the traditional way of dealing with failures in state machines. It
> works, but it is cumbersome.
Why is it cumbersome?
> > All fault situations during an action are *expected* and it
> > is a responsibility of this action to generate an appropriate
> > event that will cause a transition to a fault handling state or
> > stop the process.
> Why not let the exception slip out of the action and let the state machine
> 1. catch the exception
> 2. generate an appropriate event
> 3. dispatch that event to the appropriate state (see docs for details)
> 4. check that the event has indeed been processed and that the machine is
> in a stable state
If the framework knows all possible exception types
and appropriate events associated with them, then
this should work just fine.
The only problem I have is #4.
If all exceptions are expected, why do you need
any special checks that the event has indeed
been processed. In this case, any exception
is just a normal event (just like any other event)
and the state machine is never in an unstable state.
What do you mean exactly by stable/unstable state?
It sounds kind of disturbing when a generic state
machine framework defines some sort
of unstable states on its own.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk