Re: [boost] Re: [fsm] transition context and exit()

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-06-04 12:26:21

----- Original Message ----- 
From: "Andreas Huber" <ah2003_at_[hidden]>
[...]
> I'd also like to hear other comments. If more people with practical
experience
> would speak up in favor of your proposal then I'd reconsider adding it.

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.

I was personally fine with the requirement that
d'tor (or exit()) must not throw.
Typically when I work on a state machine,
I require that nothing in the state machine may throw.
In other words, if something throws, the state machine
doesn't care and it doesn't handle it in any way.
To me all exceptions are out the state machine domain.

I realize that it may be an old fashioned way of doing things
but it is safe and deterministic.

[...]
> 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.

> 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)?

>
> 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. :)

Eugene