Andreas Huber <ah2003 <at>  gmx.net> writes:
>  you could still lose one exception because *non-error-handling* user code
>  (the exit actions) must be executed before the problem can be handled. If
>  this non-error-handling code fails we are in deep trouble.

Yes, exit is "special".

>  IIRC, one of the 
>  reasons why to never propagate exceptions from destructors is very similar 
>  (see Herb Sutter, Exceptional C++).

Yes. The similarity had occured to me also.

>  I have reached sort of a conclusion:
>  
>  1. boost::fsm users want to have the option to just let exceptions "fly" 
>  through the framework and let the state machine client handle the problem. 
>  Whenever this happens the state machine object is no longer usable. Before 
>  handing the exception to the user, the framework should probably destruct 
(but 
>  not exit) all state objects. Users can propagate exceptions from exit actions.

A useful option.

>  2. boost::fsm users might want to gracefully handle exceptions propagated 
from 
>  actions and continue to use the state machine object afterwards. If so, they 
>  must accept that exit actions must not propagate any exceptions. This is 
>  because it seems that, no matter how action failures are handled in a state 
>  machine, in general exit actions must be executed before an error-handling 
>  state can be reached.

Agreed. Specifically, if the action failure transition is not to an inner state 
of the ICOS of the failed transition, exit actions must not throw. Of course, 
if you were to accept my proposal to allow actions to occur at any level in the 
transition, that would become ".. an inner state of the transition action 
context or the ICOS, whichever is the innermost...".

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

Regards
Darryl.

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