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 
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost