From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-05-27 10:37:04
David Abrahams <dave <at> boost-consulting.com> writes:
> > As I understood it, the argument was that to make it possible for entry
> > actions to fail it must be impossible for exit actions to fail. So to
> > me this design looks like "resource acquisition is initialization", but
> > I might be missing something.
> That argument was wrong AFAICT.
I don't think so. Exactly the same arguments as with C++ ctors/dtors apply to
entry and exit actions (and to make this very clear: I don't say this because
the boost::fsm design maps entry/exit to ctor/dtor). Why must a C++ destructor
not fail (I guess I don't have to spell this out)? Exactly the same reasons
apply to exit actions!
If C++ destructors could fail, that would make it impossible to correctly bail
out of most error situations. Exactly the same argument applies to exit
actions (even if you implement the exit action in a normal function).
> Exits happen before entries, and you
> can't undo an exit; that's status quo. If you get arrive at the point
> where an entry is about to fail, then the preceding exit didn't fail,
> so the possibility of a failing exit has no impact.
As I have tried to explain before: The problem lies in the fact that you can
have multiple exit actions called in a row before entry actions are called. If
e.g. the second of those exit actions fails (the first one succeeded) then
your state machine is in an invalid state from where it is impossible to
recover. What exactly is the loophole/problem/circularity in this reasoning?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk