The generated getState function is not intended to be called in actions and guards during state transitions. Technically, during a state transition, the state is undefined. For example, in a hierarchical state machine, the implementation represents only the leaf states; we don't represent the states that we pass through as we go up and down the state hierarchy. We need to clarify this in the documentation.
We can consider adding support for calling getState during state transitions. However, this would add complexity to the specification and implementation. For example, we would need to represent all the inner states, and we would have to specify the exact order of updating the state variable and calling action and guard functions.
The current thinking is that this complexity is unnecessary, since each implementation of a state should already know its own state. The purpose of getState is to provide a way for code outside the state machine to query the state of the state machine. It is not designed to support reflection within the state machine implementation. For behavior such as reporting the current state, the current recommended pattern is to have a periodic port handler (e.g., schedIn) periodically query and report the state outside of any transition behavior.
The generated
getStatefunction is not intended to be called in actions and guards during state transitions. Technically, during a state transition, the state is undefined. For example, in a hierarchical state machine, the implementation represents only the leaf states; we don't represent the states that we pass through as we go up and down the state hierarchy. We need to clarify this in the documentation.We can consider adding support for calling
getStateduring state transitions. However, this would add complexity to the specification and implementation. For example, we would need to represent all the inner states, and we would have to specify the exact order of updating the state variable and calling action and guard functions.The current thinking is that this complexity is unnecessary, since each implementation of a state should already know its own state. The purpose of
getStateis to provide a way for code outside the state machine to query the state of the state machine. It is not designed to support reflection within the state machine implementation. For behavior such as reporting the current state, the current recommended pattern is to have a periodic port handler (e.g.,schedIn) periodically query and report the state outside of any transition behavior.