Darryl Green wrote:
> > I think the only way to avoid the non-throwing exit actions in 2 is
> > to use the ephemeral error state or the exit() error handling you
> > proposed for *all* failures, not only for exit.
> 
>  Ok - that sounds like it would be the only sufficiently
>  regular/comprehensive alternative to (1) to be worthy of further
>  consideration.
> 
> > It is worth to explore this some more.
> > What do you think?
> 
>  I am not sure if anything other than (1) is really useful. I think
>  (2), if exception handling within the fsm framework is to be really
>  useful, is too restrictive. I think (3) (meaning 2 with the
>  modifications to allow exit to fail) might be too restrictive/hard to
>  use to be really useful. It is the last point I'd really like to hear
>  from others on. I find the idea interesting, but I wouldn't actually
>  encourage you to invest effort in implementing it at this stage.

I've thought a little about (3) and will probably let it be until I have
implemented the extensions (exit() and BOOST_FSM_RELAX_TRANSITION_CONTEXT).
Moreover, I'll make (1) the default and describe (2) as an optional feature
for the adventurous ;-).
Regarding (2) I think I have found a model that, with limitations, allows
for throwing exit(). The rules:
a. All exit() functions are allowed to propagate exceptions at any time
b. During normal operation, exit() will be called just before the state
object is destructed
c. exit() is not called when there is currently an exception "pending"
(thrown from either a state constructor, a transition action or another
exit() function). As soon as the exception has been handled (i.e. the state
machine is stable), exit() is called again in the next transition or
termination
d. exit() is never called when a state machine is destructed

These rules extend the ones already in place now. Admittedly, the whole rule
set is rather complex and I'm not even sure whether it is water-tight in all
situations. We'll see how that works out...

Regards,

Andreas

P.S. I'll be off for my holidays by Friday at the latest and not be back
before 1st of July. Unfortunately, I won't be able to implement anything
beforehand and will be swamped with other stuff when I return. So, I'm
afraid there won't be any progress before roughly mid-July. I hope you can
wait until then.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost