Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-25 20:27:10


"Andreas Huber" <ah2003_at_[hidden]> writes:

> Please have a look at the state chart at
>
> http://tinyurl.com/yrbee
>
> Let us assume that the lower orthogonal region is entered first (in
> boost::fsm this would be region 0). When we initiate this state machine, The
> states are entered in the following sequence: A, B, (exception is thrown
> while trying to enter C). When that exception is thrown then, as you rightly
> point out, we have a state machine that is in an invalid state. To bring
> this machine back into a stable state, boost::fsm now does the following:
> 1. The outermost unstable state (see definitions.html) is determined. In
> this example this is A, because the state machine never had the chance to
> enter the second orthogonal region.
> 2. An exception_thrown event is allocated on the stack
> 3. The state machine searches for a reaction for the exception_thrown event.
> It starts by examining the outermost unstable state. If that state does not
> have an appropriate reaction, it works its way outward.
> 4. Since A does have a reaction for the exception_thrown event, that
> reaction is executed.
> 5. The execution of said reaction leads to the exit of B, the exit of A and
> finally to the entry of E.
>
> Do we agree that the state machine is now in a valid (stable) state
> (assuming that the entry action of E did not throw)?

Sure, if every state whose entry action can fail has a superstate, you
can bail out and leave the machine in the superstate. Are you
requiring that? Is that superstate always a reasonable place to end
up upon failure?

FWIW, I don't know what an orthogonal region is, and I don't have time
to learn right now, so I'm probably missing a lot. If you're still
convinced you have everything right, I'll assume I'm missing something
important and stop poking at this design decision.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk