[boost] Re: [prereview request][fsm]

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