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

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-27 15:15:06

David B. Held wrote:
> "Andreas Huber" <ah2003_at_[hidden]> wrote in message
> news:loom.20040527T171933-644_at_post.gmane.org...
>> [...]
>> Why must a C++ destructor not fail (I guess I don't have to spell
>> this out)?
>
> Actually, it would have helped if you did.  The reason d'tors must
> not fail is that a fundamental guarantee of C++ is that d'tors are
> always called on exit of the enclosing scope.  Throwing d'tors
> break this guarantee.

As I said, the same applies to exit actions, see below.

>> Exactly the same reasons apply to exit actions!
>
> Not quite.  If there were a compelling reason that all exit actions
> should be called upon leaving state, then the situations would be
> analogous.
>
> But Dave is arguing that there is *not* such a
> compelling reason.  That's where the disagreement comes in.

David Harel (the inventor of state charts), the UML standard and all other
standards about state machines require that the exit action is called when a
state is left. They also require that all states are left when the state
machine is terminated. AFAICT, the only assumption I make is that a state
machine must be terminated when it is destructed. To me, this alone is
compelling enough.

However, my assumption might well be wrong and/or the standards bodies might
all have got it wrong. So lets have a look at how one typically uses entry
and exit actions. Often, something that is done in an entry action of a
particular state is undone in the exit action of the state. I'm not just
talking about the acquisition of resources. A dishwasher for example, could
turn on a Pump upon state entry and turn it off when the state is left. IOW,
FSMs frequently do rely on that an entry action call is always matched with
the correponding exit action call when the state is left (otherwise in
certain situations our Pump might continue pumping until you pull the plug).
I think everyone who has ever developed non-trivial FSMs will agree with me
on this.

Unfortunately, all FSM standards/publications I know are absolutely silent
on error handling.

Maybe I'm naive, but all I did is work out an error handling system that
under all circumstances retains the guarantee that an entry action call is
always matched with an exit action call. It is an inevitable consequence of
the guarantee that exit actions must not fail.

Regards,

Andreas