From: David Abrahams (dave_at_[hidden])
Date: 2004-05-22 21:32:47
"Andreas Huber" <ah2003_at_[hidden]> writes:
> Dear Boosters
> I think boost::fsm has finally reached a state that is worthy of a formal
> The .zip can be found here:
> The docs are also available online:
> As always: Feedback is highly welcome.
After a brief glance, it looks like a very sophisticated and
well-thought-out library. I'd like to know if following state transitions
require dynamic allocation or not.
I also have some questions about this:
> Exception handling
> Exceptions can be propagated from all user code except from state exit
> actions (mapped to destructors and destructors should virtually never
> throw in C++).
That seems like a bad limitation, and for me it calls into question
the idea of mapping state exit to destructors. Can you explain why
that's the right design?
> Out of the box, state_machine<> does the following:
> 1. The exception is caught
By the state machine framework?
> 2. In the catch block, an exception_thrown event is allocated on the
> 3. Also in the catch block, an immediate dispatch of the
> exception_thrown event is attempted.
Hum. So basically, any throwing code that could be invoked from
processing exception_thrown and from processing some other event had
better be re-entrant?
> That is, possibly remaining events in the queue are dispatched
> only after the exception has been handled successfully
I don't understand the relationship here.
> 4. If the exception was handled successfully
What does that mean? Who signals "successful handling", and how do
they do it?
> the state machine returns to the client normally. If the
> exception could not be handled successfully, the original
> exception is rethrown so that the client of the state machine can
> handle the exception
> This behavior is implemented in the exception_translator class
> template, which is the default for the ExceptionTranslator parameter
> of the state_machine class template. It was introduced because users
> would want to change this on some platforms to work around buggy
> exception handling implementations (see Discriminating exceptions).
Interesting; I'll have to look at that...
-- 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