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?