Exhaustiveness Checking
A mechanism in which the Java compiler checks sealed type hierarchies for complete subtype coverage. When a switch statement omits a branch for one of the permitted subtypes, the compiler reports an error at compile time, preventing omissions at runtime.
Timeline (last 90 days)
In combination with sealed classes, the compiler can verify whether all permitted subclasses in a switch are handled, and a missed subtype results in a compile error (exhaustiveness checking).
Exhaustiveness checking is only effective for sealed hierarchies; for ordinary open interfaces, the compiler still requires a default branch.
Exhaustiveness analysis is completed at compile time and does not rely on runtime reflection, so it brings no performance overhead.
Adding a default branch in a switch disables exhaustiveness checking, so newly added subtypes no longer trigger compile errors; therefore, unnecessary default branches should be avoided when using sealed classes.
All Facts (4)
In combination with sealed classes, the compiler can verify whether all permitted subclasses in a switch are handled, and a missed subtype results in a compile error (exhaustiveness checking).
50%UnverifiedExhaustiveness checking is only effective for sealed hierarchies; for ordinary open interfaces, the compiler still requires a default branch.
50%UnverifiedExhaustiveness analysis is completed at compile time and does not rely on runtime reflection, so it brings no performance overhead.
50%UnverifiedAdding a default branch in a switch disables exhaustiveness checking, so newly added subtypes no longer trigger compile errors; therefore, unnecessary default branches should be avoided when using sealed classes.
50%