Darryl Green <darryl.green <at> unitab.com.au> writes:
Right. This works too. I don't really understand your objection to the transition semantics I proposed.
Sorry, I didn't justify this enough. My main concern is that changes in one part of a state machine no longer lead to compile time errors in other parts, although they probably should. That is, the programmer is no longer forced to explicitly say what he means when he makes a certain type of change. For example, suppose there is an action associated with the transition between Running and Stopped. If you now move the Stopped state out of Active then said transition action is still executed before the Active exit action (i.e. the programmer is not forced to consider all the side effects of his change). I see your point that this would lead to problems only rarely, but it *can* happen. In fact, in the field where I used to employ state machines (controlling machinery) this could be a problem more than rarely because actions more often than not have global side effects (they change the state of hardware machine parts). Sure, the error very clearly lies with the programmer who failed to RTFM but he does have a point when he says "Ummm, UML mandates that all exit actions are always called before the transition action and I thought that boost::fsm claims to stick to UML, right?" Moreover, I think it is much more readable this way (although we should probably find a better name for compound_transition) and I hope that other people will agree. I do see some merit in your proposal, I just think it is much too early to make such a change with just you and me considering the implications (once the change is made we cannot go back without breaking existing code).
I'm done on this one, but I would like to hear other comments
- I have to agree with Rob Stewart that it is a bit too quiet around here (though I'm not convinced that we need fsm "experts" - I'm sure there is plenty to be offered by those untainted by too much
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. previous
fsm experience).
Agreed. People with a lot of experience with FSMs are often convinced that the way how they usually solve a particular problem is the best. As a result they could fail to use new features of boost::fsm in previously unknown ways. As you know, this happended to me as well. I never considered to use your "pre- exit" trick although I definitely could have benefited from it in the past too.
I think you could allow exit() failure,
Definitely not in this particular situation. This would be the same as allowing a destructor to throw. I know I said this before and people rightly argued that I'm wrong. But here we really have the same situation because a second exception is thrown (from exit()) while we are *unwinding* from a first exception (thrown from the transition action). Now you suddenly have two exceptions. Which one are you going to handle? Since you can only catch one of them the other one is inevitably lost.
I don't think it is really the same as throwing while unwinding - or are you saying that the implementation would have to be such that it genuinely was exactly that?
No. It could be implemented such that the first exception is always caught in a catch handler before the second exception is thrown. boost::fsm currently doesn't do so for performance reasons. But, even if it did 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.
I envisioned that the transition exception would be caught and converted to an event. The event would be (must be) queued (in a queue of depth 1) while doing the exit action.
boost::fsm can't queue events resulting from an exception as that could involve a dynamic allocation. I think it's not a good idea to do that while handling an exception.
If the exit threw, this would be handled immediately (in line with the exit exception proposal outlined previously), but the transition exception would *not* be lost.
What if we fail to handle the exception thrown from the exit action? I know you said that it must not fail, but what do we do when it fails anyway? We cannot force the user to handle the exception, right? We'd need to propagate the exit action exception to the state machine client, but the first exception is inevitably lost. Alternatively we could also lose the second exception and propagate the first one, but still one exception is lost. IIRC, one of the reasons why to never propagate exceptions from destructors is very similar (see Herb Sutter, Exceptional C++).
Thoughts?
I'm not claiming any particular expertise or experience here - my first reaction, which seems pretty common, is to be very keen to avoid mixing fsms and exceptions at all. I certainly want at least the option of the simple behaviour of just abandoning the fsm and propagating the exception. If anyone else is still interested in giving serious consideration to other options, I'd be interested in continuing to try to work something out, otherwise
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. 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 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. What do you think? Regards, Andreas