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
for you.
> > 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
back
> > 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.
Regards,
Andreas