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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost