Boost logo

Boost :

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

Andreas Huber <ah2003 <at>> writes:
> David Abrahams <dave <at>> 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
> 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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at