Skip to content

Explain dead ends in failing state transitions - #412

Open
CatarinaGamboa wants to merge 1 commit into
feat/state-hints-callsfrom
feat/state-hints-dead-ends
Open

CatarinaGamboa wants to merge 1 commit into
feat/state-hints-callsfrom
feat/state-hints-dead-ends

Conversation

@CatarinaGamboa

Copy link
Copy Markdown
Collaborator

Stacked on #411.

Description

When no call can fix a failing state transition, the error now says why:

  • Unreachable state: no sequence of calls reaches a state where the call is allowed. The hint suggests a constructor that creates the object in such a state, if one exists.
  • State depending on the path taken: the object can be in several states (e.g. after an if), and no single sequence of calls works for all of them.
  • Final state: no method with a state refinement can be called in any of the states the object can be in.

These hints claim that something is impossible, so they are only given when the machine is complete. That means every state-changing method of the class is modeled, and no superclass or subclass has state refinements of its own. When nothing is known about the state, these hints are not given; the next PR handles that case.

StateMachineBuilder now also records the states each constructor creates, when they only depend on the state of this.

Example

f.close();
f.read(); // read() needs open
 --> No sequence of calls moves f from closed to open. Create a new object instead with new File()
     f is in state closed, where none of its methods with state refinements can be called

Type of change

  • New feature

Checklist

  • Added tests:
    • ErrorStateHintFinalState and ErrorStateHintPathDependent.
    • ErrorStateHintIncomplete (a transition depends on an argument) and ErrorStateHintSubclass (a subclass adds a transition) get no dead-end claim.
    • ErrorStateHintSeveralRefinements now gets the path-dependent hint.
  • mvn test passes locally

🤖 Generated with Claude Code

When no sequence of calls leads to a state that allows the failing
call, the error says so and suggests the constructors that create the
object in such a state, or, if the object can be in several states
depending on the path taken, asks for the same state on every path.
When no call is allowed in the object's state, the error says it is a
final state.

These claims are only made when the state machine models every
state-changing method of the class and of its super and subclasses.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant