--- Andreas Huber <ah2003@gmx.net> wrote:
E. Gladyshev <eegg <at> comcast.net> writes:
If the entry or exit action throws, the state machine is in undefined state... unless you define the throw event as a legitimate event which causes a transition. However I don't see how this can be done generically.
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? If so does it mean that all unspecified exceptions won't be caught by the framework?
In our project, we decided: 1. The state machine *framework* never catches user exceptions. 2. The framework doesn't have a concept of failed actions at all. Any action has to be completed.
This is the traditional way of dealing with failures in state machines. It works, but it is cumbersome.
Why is it cumbersome?
All fault situations during an action are *expected* and it is a responsibility of this action to generate an appropriate event that will cause a transition to a fault handling state or stop the process.
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. 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? It sounds kind of disturbing when a generic state machine framework defines some sort of unstable states on its own. Eugene