State machines, for example UML state machines, statecharts or other finite state machines, allow actions to be executed when a state machine takes a transition between states or is within a state.
In programming languages with exceptions, exceptions can occur within such actions, even if you disallow checked exceptions for actions in programming languages that have checked exceptions or disallow exceptions all together. In programming languages like Java or Ada exceptions are part of the semantics of the language, for example OutOfMemoryError or Constraint_Error, and can occur at many points. So state machines have to handle them somehow.
Events are often enqueued on an even event queue of the state machine and handled asynchronously. Therefore, it is impossible to propagate an exception to a caller. So far I found two methods of handling exception in actions of state machines:
- Invoke some exception handler callback of the state machine, source or target states or transition that is being taken. The North State Framework for UML state machines uses this method.
- Generate an event for the exception and handle that event in the state machine. This has been described in Modeling and Analysis of Exception Handling by Using UML Statecharts.
However, it is unclear to me what an exception during a transition means for the semantics of state machines. Some questions that come to mind are:
- Is the transition taken when the exception occurs?
- Is it equivalent to a guard expression that evaluates to false and does the state machine have to consider other conflicting transitions with lower priority?
- Is the event considered to be handled or should the state machine try to reprocess it after an exception handler has been invoked?
- What about the side-effects of actions of transitions that have been executed before exception occurred?
- What is the priority of the event that is generated for the exception if there is one?
The more I think about it, the more questions come up. Unfortunately, the UML specification and other descriptions of state machine notations do not consider exceptions. Even the Precise Semantics of UML State Machines do not consider them.
Do you have additional ideas how handle exceptions in state machines? What are the semantics of a transition if an exception occurs in its action?
Best Answer
State machines don't have exceptions, though they may have transitions to an error state.
There's no “one size fits all” answer for how you should handle errors. This depends a lot on the problem domain. Possibilities I consider useful:
If an exception occurs, this is interpreted as a transition to an error state. This error state may be terminal, i.e. aborts further event handling. This would be effectively equivalent to not handling the exception in your state machine but letting it bubble up to the user of the state machine. Such an approach seems sensible if the cause of the exception does not lie in the events, but in your implementation, i.e. the exception can't be handled by your model of the state machine.
The error state could also be non-terminal, and offer further transitions. This corresponds to a try-catch. Such an approach is particularly desirable when the state machine must not terminate. This is generally applicable if the cause of the error is in the sequence of events, and can therefore be modelled.
How this meshes with event handling depends. You can't really re-apply an event that led to an exception. It would usually be sensible to consume the event with the transition to an error state.
I'd also like to point out that state machines are often desirable because we can prove many properties about the state machine in advance, e.g that it must terminate. An out of memory error can often be avoided since the memory usage of a DFA is bounded. As such, you shouldn't expect to see any exceptions, and should model error cases that are to be expected as explicit state transitions: either the state machine has a bug, or the state machine will successfully handle the “language” of events that is submitted to the state machine.