assertNever accepts a value typed as never and throws at runtime. The compile-time win is that, after every other branch narrows away its share of the union, the leftover variable must be never for the call to type-check. Add a third variant to Shape and TypeScript reports an error at the assertNever(shape) line because shape is no longer never there. Throwing in the body keeps runtime behavior loud (instead of silently returning undefined) so the bug surfaces immediately if exhaustiveness was bypassed via as.

switch on the discriminator (action.type) is the most ergonomic shape for a reducer because each case body can use the narrowed action type for free (TypeScript figures out which branch you are in from the literal). Putting assertNever(action) in the default makes the entire reducer exhaustive: add an Action variant and TS reports an error at the default until you handle it. This is the canonical pattern for typed Redux/Zustand stores, parser dispatch tables, and event handlers, and it composes cleanly with branded types and ValueOf constants.

Throwing in production is right for invariants you fully control, but for inputs that arrive from the wire (older clients, third-party webhooks, server-deployed-before-client cases), a soft fallback that logs and continues is safer. The assertNeverSoft variant keeps the static-exhaustiveness benefit (the call signature still requires never, so TS catches missing branches at compile time) while letting the runtime degrade gracefully. Use it at trust boundaries; use the throwing version inside pure logic where any unexpected variant truly is a bug.