"Andreas Huber" <ah2003@gmx.net> wrote in message news:c95sjg$a4o$1@sea.gmane.org...
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
[...]
No. Please have a look at http://tinyurl.com/2uzs5 (the whole section on Exception Handling) again. I think it clearly explains how it all works.
It does. The reason I asked is that in #4, you are saing that an exception renders the state unstable (if I understood it right). The definition of unstable state is "A state is unstable from the moment when it has been entered until just before its last direct inner state is entered. Once a state is stable it can only become unstable again by being the innermost common outer state in a transition." So for the state to be unstable there must be an inner state. So if an *innermost* state action generates an exception, how can it become unstable?
I think that one of the most important goals of the state machines design is to achieve a completely deterministic behavior.
Yes, this is important for me also.
Doesn't your default exception handling idiom compromise this objective?
Do you think so because finding a handler for an exception might take non-deterministic time?
I meant a behavioral determinism (not temporal) where all states and transition are *explicitly* defined by the state machine designer. For instance if the state machine is in some state I can tell exactly what events might have caused it and what state the client is in and what is the next possible state may be. My concern was is that if the framework is adding some *implicit* transitions upon exceptions the above explicit determinism is gone? Eugene