E. Gladyshev wrote:
>  ----- Original Message -----
>  From: "Andreas Huber" <ah2003@[...].net>
>  [...]
>  It's been a long discussion.
>  It'd be helpful if you could summarize the proposed changes
>  on d'tor/exit() and exception handling in general.

Ok, I will.

> > I have reached sort of a conclusion:
> >
> > 1. boost::fsm users want to have the option to just let exceptions
> > "fly" through the framework and let the state machine client handle
> > the problem. Whenever this happens the state machine object is no
> > longer usable. Before handing the exception to the user, the
> > framework should probably destruct (but not exit) all state objects.
> 
>  If "fly through" is what I think it is (exceptions are not caught by
>  the framework),
>  it is one or another. You cannot "let exceptions "fly" through the
>  framework"
>  and destroy all states at the same time.

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). This ensures that the state machine object is
in a defined state if client code uses it after handling the exception.
State objects are constructed on state entry. On state exit, the states
exit() function is called (if present) and the state object is destructed
afterwards. Exceptions can be propagated from all user code except state
destructors.

> > 2. boost::fsm users might want to gracefully handle exceptions
> > propagated from actions and continue to use the state machine object
> > afterwards. If so, they must accept that exit actions must not
> > propagate any exceptions. This is because it seems that, no matter
> > how action failures are handled in a
>  state
> > machine, in general exit actions must be executed before an
> > error-handling state can be reached.
> 
>  I believe that it is similar to how things
>  work now (with the default ExceptionTranslator)?

Yes.

> > I think the only way to avoid the non-throwing exit actions in 2 is
> > to use the ephemeral error state or the exit() error handling you
> > proposed for *all* failures, not only for exit. It is worth to
> > explore this some more.
> >
> 
>  "ephemeral error state" makes me nervous. :)

Me too. I haven't got very far yet on the precise semantics. Whenever I try
to formulate how exit() failures are handled I find myself trapped in
inconsistencies. Contrary to Darryls proposal my gut feeling is that we have
not left a state when its exit action fails. As a result, the exit() action
of a particular state object could be called more than once, which I find
*very* strange. Maybe Darryls way to handle things is better nevertheless
...

Regards,

Andreas


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