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