|
Boost : |
From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-05-27 19:58:22
"Andreas Huber" <ah2003_at_[hidden]> wrote in message
news:c95sjg$a4o$1_at_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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk