[boost] Re: [prereview request][fsm]

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:
>
> http://boost-sandbox.sf.net/fsm.zip
>
> The docs are also available online:
>
> http://boost-sandbox.sf.net/libs/fsm
>
> 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
http://www.boost-consulting.com