Statecharts handle off nominal

Statecharts have a natural flare for handling error cases and situations that are off the happy path.

Traditional “bottom-up” approach

In a lot of bottom-up approaches, it is common to forego the error states: When an error occurs, it’s caught by a high level error handler and a generic error message is shown to the user. The user interface is often left in an unknown state; the booleans and other variables that control the UI might be set in some unexpected way because of the error. Errors like this are rarely sought out, they rarely appear in testing, and often cause the interface to crash or behave in unexpected ways in the field.

Statechart approach

In a statechart approach, failures are generally failures of background activities. When a background activity fails, a simple thing to do is to inform the statechart about the failure (by sending an event that describes the error), and describe in the statechart how the failure should be handled, typically by introducing a new transition to deal with the error.

This simple act causes the error to be explicitly visible in the statechart, and therfore to the development team and other stakeholders. It allows QA teams to discover that the error state exists, possibly prompting them to actually test this path. It allows designers to design the error states that have been uncovered.