From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-27 11:51:16
E. Gladyshev <egladysh <at> yahoo.com> writes:
> > 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?
Yes, you can do that if you want (it is a per state machine policy). The
default is to always dispatch an exception_thrown event.
> If so does it mean that all unspecified exceptions
> won't be caught by the framework?
Yes, you can do that. The default is to catch all exceptions.
> > This is the traditional way of dealing with failures in state machines. It
> > works, but it is cumbersome.
> Why is it cumbersome?
Because you have to write lots boiler-plate code yourself (catch the exception
and post the error event in a lot of actions). The framework can automate this
> > Why not let the exception slip out of the action and let the state machine
> > framework:
> > 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.
It doesn't typically have to. I think the default behavior is ok for most
projects. See http://tinyurl.com/2uzs5, Discriminating exceptions.
> 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?
See http://tinyurl.com/2bjjw, Unstable state machine
> It sounds kind of disturbing to me when
> a generic state machine framework defines
> some sort of unstable states on its own.
I don't think so, the behavior is clearly defined and just automates what
you'd do manually anyway.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk