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.
I think the only way to avoid the non-throwing exit actions in 2 is to use
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...". 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.