Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-23 20:05:55


"Andreas Huber" <ah2003_at_[hidden]> writes:

> I don't think I have missed your point and I know that I'm talking to an
> exception handling expert. Have you read that whole paragraph?

Yep

> Agreed, after
> posting I noticed that the first half isn't exactly the best explanation of
> why exit actions must not fail. However, I believe that the second half is a
> good argument why throwing exit actions are a bad idea:
> <quote>
> ... However, even if exit actions are called in the
> course of a normal transition what are you going to do if B's exit action
> throws an exception?

Stay at B, of course (?)

> Technically, the state machine still resides in B, so
> you have pretty few options for continuing. You cannot exit A as that would
> violate the state machine invariant that inner states are always exited
> before outer states. You cannot make a transition to another state, as that
> would also require successful exit from B. So, the only sensible thing is to
> try to handle the error inside B's exit action.

I don't understand why. The user of the FSM could handle the
exception on the outside if its state doesn't change.

> If the error cannot be handled there it must either be ignored or,
> in the case of a really serious error, be handled with a different
> mechanism than exceptions. </quote>
>
> A maybe more convincing argument:
> In the course of a transition a state entry action throws an exception. Note
> that the state machine is in an invalid state (unstable) when this happens.
> If the state machine does not successfully handle the exception, the
> exception must be propagated to the state machine client. Because the state
> machine is unstable, it *must* be terminated before propagating to the
> client.

OK so far...

> Termination calls the exit actions of all currently active states.

that sounds like it could be the wrong design decision, to me.

> What are you going to do with exceptions thrown by these exit actions?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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