Re: [boost] [review] FSM Second Call for Reviews

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-30 02:55:57

Chris Knight wrote:
> 
> I do note my agreement that transition handler concept should be allowed to 
> return values on invalid events rather than be forced to throw exceptions 
> since in many cases an invalid event for a particular state is an error only 
> when viewed at the level of the state machine's "protocol" and often times 
> occurs just as often as the situation in which there is a valid match. 
> 
> This is somewhat provided with the switch_to<> mechanism however this seems to 
> exist outside the realm of the well-defined state machine's transition rules. 

There's no connection between unexpected events handling and the
switch_to mechanism. Unexpected events are detected before the FSM has a
chance to call switch_to (effectively, such events are detected at
compile time).

> This approach forces error handling into what would best be 
> described as the lexer (state_machine::process()'s callee) and thus outside 
> the domain of the state machine.

I disagree. When an event is unexpected, there's no handler in the FSM
that would be able to handle it. This is the whole point behind the term
"unexpected".

Since, as you said yourself, such unexpected events may actually appear
quite often, the library must provide an option to customize the
behavior when receiving them. This is accomplished with the unexpected
events handler, which is basically a user-provided functor, that is
called on such event receipt.

> A better approach would be to allow dynamic 
> posting of events from within transition handlers. These "error events" are 
> thus included in the definition of the state machine's transtition table.

This would make these events quite expected. You can already include
such events in the transition table and have the desired behavior. As
for event posting, there's been a discussion about it during the review.

> Furthermore, while CTM's example fsm does not allow transition handlers to 
> prevent the transition from "matching", it mirrors my internal 
> implementation in most other regards as it too is implemented as 
> fold(transitions_for_current_state, default_event_dispatcher, 
> event_dispatcher<_2, _1>>).

That's because the transition is matched at compile time only.

> The last note I would make regards the BOOST_FSM_MUST_HANDLE_ALL_EVENTS macro 
> one uses to enforce compile-time state machine consistency. This is rather a 
> suprise as my expectation would be for this to be an intrinsic function of an 
> fsm. 

Do you mean that the FSM should never compile if it detects unexpected
events?