Go's compiler never checks that a switch covers every constant of a type — how do you stop an unhandled case from failing silently?

## The gap Go has no enumeration type. A set of related constants is just typed integers: ``` type tokenKind int const ( tokIdent tokenKind = iota tokNumber tokString ) ``` A `switch` over `tokenKind` is an ordinary switch over an integer. The compiler has no notion that these three values are "all of them", so it cannot warn that you handled two. `go vet` does not check it either — vet's analyses look for suspicious constructs like printf argument mismatches and lost struct tags, not domain completeness. And there is no compiler flag that changes this. The result is a specific, quiet failure mode. Someone adds `tokComment` to the constant block. Every switch over `tokenKind` in the codebase still compiles. The ones with a `default` take it; the ones without simply fall out and leave the result variable at its zero value — `""`, `0`, `nil`. The program keeps running and produces subtly wrong output, and no tool has said a word. ## Layer one: make the miss loud The first and cheapest defence is to decide what an unmatched value *means* and say so: - If reaching `default` would be a **programmer error** — an internal value that the compiler cannot prove is one of a known set — `panic` with the value in the message. A panic in a unit test is a failed test; a panic in production is a crash that names the exact unhandled constant, which is far better than silent corruption. - If the value can arrive from **outside** the program (a wire format, a config file, a database column), it is not a programmer error, so return an explicit error or a `(value, ok)` pair and force the caller to handle it. What you must not write is `default:` with an empty body or a bare zero return added to quiet a reviewer. It converts a bug into plausible data: a missing case that falls out of the switch already produces the zero value, but a written `default: return ""` looks deliberate, so nobody asks about it again. ## Layer two: a sentinel constant plus an enumerating test The rule you actually want — "adding a constant must force someone to visit every switch" — cannot be expressed to the compiler, but it can be expressed to the test suite. Add a sentinel as the last constant so the count maintains itself, then enumerate: ``` const ( tokIdent tokenKind = iota tokNumber tokString numTokenKinds // sentinel: always last ) func TestEveryKindHasADescription(t *testing.T) { for k := tokenKind(0); k < numTokenKinds; k++ { if describe(k) == "" { t.Errorf("token kind %d unhandled by describe", k) } } } ``` Adding `tokComment` before the sentinel raises `numTokenKinds`, the loop reaches the new value, `describe` returns the zero value or panics, and the test fails with the kind number in the message. That is the closest thing to an exhaustiveness check the language offers, and it costs six lines. It works only because the sentinel is derived from the constant block rather than hand-maintained — a hand-written `const numKinds = 3` is one more thing to forget. Note what this does *not* give you: a compile error. A fixed-size array sized by the sentinel, `[numTokenKinds]string{...}`, catches an index past the end, so it will fail the build if constants are removed or reordered past the array's length, but adding one simply leaves a zero entry. Adding still needs the test. ## Layer three: coverage as the check on the test `go test -coverprofile=cover.out ./...` followed by `go tool cover -html=cover.out` renders every statement your tests never executed. A case body that exists but is never entered shows up red. Be precise about what this proves, because it is a favourite interview follow-up: coverage reports the statements you **wrote**, not the ones you **forgot**. It can never reveal a missing case. What it reveals is the complementary failure — a clause you added and then never exercised, which usually means the enumerating test above is not actually reaching it, or that the case is dead. Treat coverage as an audit of your tests, not as an exhaustiveness tool. ## Layer four, for constants that cross a package boundary If the constant block is exported and other packages switch over it, adding a value is a behavioural change for code you do not compile. Your enumerating test protects your own switches and nothing else. The realistic controls are to document that consumers must have a fail-closed `default`, to note the addition prominently in the release, or — the strongest option — not to export the constants at all and hand out a function that returns the mapping, so there is exactly one switch in the world and it is yours. ## Summary No compiler check, no vet check. Give the switch a `default` that panics or errors instead of returning a plausible zero; derive a sentinel constant from the block and enumerate it in a test so adding a value fails the build; use coverage to confirm every clause you wrote is actually exercised; and for exported constant sets, treat adding one as a contract change.