E. Gladyshev wrote:
>  "Andreas Huber" <ah2003@[...].net> wrote in message
>  news:c9qra1$2mq$1@[...]..
> > 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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost