Andreas Huber <ah2003 <at> gmx.net> writes:
David Abrahams <dave <at> boost-consulting.com> writes:
I wish you had; I'll just have to take your word for it because I'm out of time for discussion. Your method of handling errors as described above seems (with my very shallow understanding) a bit capricious and hard-to-manage to me, and it seems strange to keep that system while ruling out a chance for strong-guarantee behavior (where an exit action may throw).
Ok, opinion taken. I'll update the rationale section and try to very clearly explain: - How one typically handles errors in traditional FSM frameworks (which
don't
allow for failing actions) and how this led to the design of the error handling mechanism in boost::fsm, which essentially only automates what you have to do manually otherwise. - Why failing exit actions are a bad idea.
I'm looking forward to convince you in the formal review .
Maybe I'm just being thick, but the whole idea of a failing exit action seems rather odd to me. This has nothing to do with whether the exit action is a destructor or not. The state is trying to take a transition, it basically has done so, the transition action has run, and - whammo - we fail and want to get back into the state being exited? Why? So we can fail to exit it on the next event? Alternatively, we want to go to a new state because of this failure - not to the one we have already launched into the transition for - once again - this seems ugly, we have now turned the failing exit action into some sort of guard. If that is what it is supposed to be, why not just write it as one? I think it is important to note that it is perfectly possible (afaik) to implement an arbitrary FSM without using entry or exit actions at all. It doesn't seem like a bad idea to reserve these for RAII use, and do all other work in actions. On a vaguely related note - I have a question about in-state transitions. There is an example of a custom reaction to do this. However, there is no provision for an action associated with this transition. Obviously it is possible to write the action (or call it) as part of the custom reaction, but this seems irregular for a library that is trying to map directly from/to UML. My eyes glazed over a bit trying to follow the transition handling code to add some sort of an in_state_transition<> but the concept seems trivial enough. Having this facility means that the same action can be used for an in-state transition as for other transitions, which seems only reasonable, and the similar declaration should make developing/modifying a state's transitions easier. For that matter, I suppose the transition could actually specialise for the particular case of a transition back to the source state, and no special declaration would be needed? Regards Darryl.