Boost logo

Boost :

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-05-27 19:58:22

"Andreas Huber" <ah2003_at_[hidden]> wrote in message

> > Why not let the exception slip out of the action and let the state
> > 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
> > in a stable state

> No. Please have a look at (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

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

> > 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
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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at