Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-24 04:50:27


David Abrahams <dave <at> boost-consulting.com> writes:

> > Ok, I seem to finally see your point. You would want to leave the state
> > machine in a possibly *invalid* state when propagating the exception to the
> > state machine client, right?
>
> No. I said it should stay in the same state it was already in.
> Presumably the exit action is the first thing that would happen on a
> transition (?)

Right.

> , so if it fails, you haven't gone anywhere and the
> machine should still be in a valid state.

This can only be guaranteed if your state machine is flat and does not have
orthogonal regions. If you either have nested states and/or orthogonal regions
you frequently need to exit more than one state. If the first exit action
fails then, yes, the machine is still in a valid state. However, if the first
one succeeds and any of the other exit actions fails then you're doomed. Your
state machine is now in an invalid state and there's nothing you can do to
bring it back into a valid state, short of terminating by not calling exit
actions (see below).

> > So what is the user then doing with the state
> > machine object after handling that exception? Since the machine might be
> > unstable he cannot process any more events. What's even more disturbing is
> > the fact that he cannot even successfully destroy the state machine. Or are
> > you proposing that the exit actions of the still active states should not
be
> > called upon destruction?
>
> I am proposing that. Leaving a state via transition seems
> fundamentally different from what must happen when you're simply done
> using a state machine and it is destroyed.
>
> >> that sounds like it could be the wrong design decision, to me.
> >
> > Ok, but how do you propose should the state machine then be terminated? By
> > simply not calling the exit actions of still active states?
>
> Yes, why not?

Because that would essentially be the same as destructing an object by not
calling its destructor (i.e. by only deallocating the memory). I'm not only
saying this because an active state happens to be an object in boost::fsm.
State machines frequently acquire resources in entry actions and dispose of
them in exit actions. Those resources would simply be leaked if there's no
guarantee that exit actions are called under all non-fatal error situations.

Regards,

Andreas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk