E. Gladyshev wrote:
"Andreas Huber" <ah2003@gmx.net> wrote in message news:c9qra1$2mq$1@sea.gmane.org...
E. Gladyshev wrote: [...]
What I meant was the default behavior we were talking about before. I rephrase, trying to stick more to accepted exception handling terminology: 1. By default, boost::fsm is completely neutral to exceptions. All exceptions thrown by user actions are propagated to the state machine client. If such an exception is caught by client code, all state objects are destructed (but not exited).
I know where the confusion is. I don't think that the last statement is technically correct. The fact that the client catches the exception doesn't guarantee that the state objects are destructed.
Hmmm, I guess I misinterpreted your earlier comments regarding unhandled exceptions then, see below.
fsm::state_machine<...> machine; try { machine.initiate(); } catch(...) { ... }
OR
try { fsm::state_machine<...> *m = new fsm::state_machine<...>(); m->initiate(); } catch(...) { ... }
Do you mean when the state machine object goes out of scope or deleted?
I thought that in both cases it is guaranteed that the stack is unwound (when we enter the catch ( ... ) handler). If so, then the scope guard inside initiate() will destruct all state objects. Inside the catch ( ... ) handler the machine object is therefore in a defined state (machine.terminated() returns true). I interpreted your earlier comments such that stack unwinding is not guaranteed *only* when we never catch the exception propagated out of the state_machine<>::initiate() function. As soon as the exception is caught somewhere the stack will unwind and the machine object is in a defined state when it is accessed. What am I missing? Regards, Andreas