Boost logo

Boost :

From: Andreas Huber (ah2003_at_[hidden])
Date: 2004-06-05 05:15:43


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk