E. Gladyshev wrote:
As for unstable states. Does this idiom mean that any exception event handling state must be considered as an implicit *inner* state of any other state that throws? So that *only* the exception handling states can be considered as *most inner* states.
No. Please have a look at http://tinyurl.com/2uzs5 (the whole section on Exception Handling) again. I think it clearly explains how it all works.
I think that one of the most important goals of the state machines design is to achieve a completely deterministic behavior.
Yes, this is important for me also.
Doesn't your default exception handling idiom compromise this objective?
Do you think so because finding a handler for an exception might take non-deterministic time? That is true on some platforms. On others you *can* establish upper limits for finding a handler. I chose the default this way because I believe that a majority of the users will not have deterministic reaction time requirements. In real-time projects you often disable exceptions anyway so the problem won't arise. I will add a remark that real-time projects should consider not using exceptions or check that the compilers exception handling implementation is deterministic. Regards, Andreas