Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-28 01:55:33

E. Gladyshev wrote:
> 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.

No, the term is "innermost common outer state", not "innermost state". The
innermost common outer state is only defined during a transition and is
exactly the same as the LCA, see definitions.html.

> I meant a behavioral determinism (not temporal) where
> all states and transition are *explicitly* defined by the state
> machine designer.

This still applies in boost::fsm. If you don't define any reactions for the
exception_thrown event, your state machine will simply terminate when an
exception is thrown. If you want to react to such exceptions you must
explicitly define exception_thrown reactions. What makes you think

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

Well, since the state machine is terminated when you fail to handle the
exception_thrown event, you could argue that the exception handling system
does add one reaction (the termination). Is that what you are referring to?



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