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

From: Chris Knight (cknite_at_[hidden])
Date: 2008-08-31 02:58:27

On Saturday 30 August 2008 1:55:57 am Andrey Semashev wrote:
> 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).

Sorry, I should have chosen my words more carefully. What I meant by 
an "invalid event" in this case was really an "error event" - a well defined 
event that simply is posted from within another event handler to handle 
protocol level errors. My only point was that one could implement a 
post_event via the switch_to<> functionality. 

> > 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".

Once again f(x) := "invalid => error" transforms my statements to more 
sensible ones. :-)

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

Completely in agreement as there are really 3 forms of events. 

*) Expected and "correct" ones (a network packet with the next expected 
seqnum)
*) Expected but "incorrect" ones (a packet with a seqnum indicating packet 
loss)
*) Unexpected events (events that do not conform to the state machine)

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

Yes. If I say state_machine.process(Logon) when, for instance, the machine is 
in the Disconnected state I would expect that to be detected by default if 
for no other reason than the cost of doing so should be trivial/zero since 
the check is done at compile time. It could potentially matter with the 
addition of a post_event functionality as that would necessarily add the 
additional requirement of state machien variant checking in the machine's 
event double dispatcher that would process and dispatch posted base_events.