From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-06-04 11:30:11
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'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.
> - 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
> 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
> > argued that I'm wrong. But here we really have the same situation because
> > second exception is thrown (from exit()) while we are *unwinding* from a
> > exception (thrown from the transition action). Now you suddenly have two
> > exceptions. Which one are you going to handle? Since you can only catch
> > 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
> event. The event would be (must be) queued (in a queue of depth 1) while
> 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
> else is still interested in giving serious consideration to other options,
> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk