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

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-25 12:38:43

Andreas Huber <ah2003_at_[hidden]> writes:

>> If anything, I'd want to prohibit exceptions in entry actions,
>> since those can lead to the FSM being in a state from which it's
>> impossible to continue.
>
> Interesting, it seems "failure-proof" entry actions would be an
> inevitable consequence when you allow failing exit actions.

Not AFAICT.  Even if you don't allow exit actions to fail, how will
you recover from a failed entry action?

I am assuming here that when going A->B, you exit A before you enter
B.  If you're doing it in the other order, of course, my arguments
don't apply.

>> At least with exit actions, you can stay where you are and keep all
>> your FSM's abstract invariants intact.
>
> As I have already pointed out: Only if your machines are flat and non-
> orthogonal, right?

I don't understand what you mean.  Certainly w.r.t. "flat", only one
exit action in a stack of nested states can be allowed to fail.

> My approach is almost symmetrical to yours, isn't it? Since I allow
> failing entry actions I am forced to disallow failing exit actions.

I don't understand that.  You can't neccessarily re-enter a valid
state if you've already exited and entry throws an exception.

> With your approach exit actions can fail what forces you to disallow
> failing entry actions.  In both approaches allowing the failure-proof
> action to suddenly fail can result in an FSM having an invalid state
> from where it is impossible to recover.
>
> However, I consider my approach superior because I can guarantee that
> for every successfully completed entry action there will always be a
> matching call to the exit action. You cannot give such a guarantee.
>
>> > If this is needed only rarely I'd rather have users work around
>> > the problem by setting a boolean and posting an error event in a
>> > failing exit action and then testing that boolean in all following
>> > exit actions.
>>  Eeeeew, that's gross.  Sorry, but that just smells like an awful
>> hack.
>
> I very much agree. But don't we have to do the same when we want to
> signal a destructor failure?

Circular argument again ;-)

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com