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? Regards, Andreas