Boost logo

Boost :

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
> review.
> 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
> stack
> 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

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