[boost] Re: [prereview request][fsm]

From: Darryl Green (darryl.green_at_[hidden])
Date: 2004-05-26 23:30:20

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.