----- Original Message ----- From: "Andreas Huber" <ah2003@gmx.net> [...]
I'd also like to hear other comments. If more people with practical experience would speak up in favor of your proposal then I'd reconsider adding it.
It's been a long discussion. It'd be helpful if you could summarize the proposed changes on d'tor/exit() and exception handling in general. I was personally fine with the requirement that d'tor (or exit()) must not throw. Typically when I work on a state machine, I require that nothing in the state machine may throw. In other words, if something throws, the state machine doesn't care and it doesn't handle it in any way. To me all exceptions are out the state machine domain. I realize that it may be an old fashioned way of doing things but it is safe and deterministic. [...]
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.
2. boost::fsm users might want to gracefully handle exceptions propagated from actions and continue to use the state machine object afterwards. If so,
If "fly through" is what I think it is (exceptions are not caught by the framework), it is one or another. You cannot "let exceptions "fly" through the framework" and destroy all states at the same time. 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 believe that it is similar to how things work now (with the default ExceptionTranslator)?
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. It is worth to explore this some more.
"ephemeral error state" makes me nervous. :) Eugene