How do you handle an unknown key in a Python dict dispatch table without masking errors raised by the handler?

## Three ways to look up, and only two of them are safe A dispatch table has to answer one more question than the mapping itself does: what happens when the key has no handler? Python offers three shapes, and the difference between them is precisely where the boundary of the error handling falls. **Subscript with a default handler.** `handlers.get(kind, fallback)` returns `fallback` when the key is absent. It is the most compact form and it is correct as long as `fallback` is a callable with the same signature as every real handler, so the call site can invoke whatever came back without knowing which it got. This is where a `report_unknown(record)` or a no-op handler goes. **Lookup, test, call.** ```python handler = handlers.get(kind) if handler is None: raise ValueError(f"no export handler for {kind!r}") return handler(record) ``` This is the shape to reach for when an unknown key is a defect rather than a case. It fails loudly, and crucially the error message names the offending key — the single most useful thing a dispatch failure can tell you, because the caller usually has no idea which of a thousand records carried it. It also keeps the call strictly outside any error handling. **Subscript inside a try block.** This is the trap: ```python try: return handlers[kind](record) except KeyError: return handle_unknown(record) ``` The `try` block covers *both* the subscript and the call, and `KeyError` is one of the most commonly raised exceptions in Python — every dict access inside the handler can raise one. So a handler that does `record["customer_id"]` on a row missing that column raises `KeyError`, the `except` clause catches it, and the record is quietly reclassified as "unknown type". In an ETL export to a warehouse that is a silent partial failure: the job reports success, some rows land in the reject path for the wrong reason, and the mismatch is only discovered downstream when totals do not reconcile. The same shape hides `KeyError` from environment lookups, JSON payload access, and cache reads inside the handler. If you want the EAFP style, narrow the block to the lookup alone: ```python try: handler = handlers[kind] except KeyError: raise ValueError(f"no export handler for {kind!r}") from None return handler(record) ``` Now the call happens outside, and anything the handler raises propagates as itself. `from None` suppresses the chained `KeyError` context when the message would be noise; keep the chaining when the original is informative. ## Why collections.defaultdict is the wrong tool here `collections.defaultdict` is a tempting one-liner and a poor fit for dispatch, for two reasons. Its `default_factory` is called with no arguments, so the default handler cannot be chosen based on which key was missing, and it cannot even report the key it was standing in for. And a miss **inserts**: every unknown key permanently adds an entry, so a table fed by untrusted input grows without bound and its `keys()` stops describing what the program actually supports. `dict.setdefault` has the second problem too, and additionally evaluates its default argument on every call whether or not it is needed. Plain `dict.get` with a default does neither: it mutates nothing. ## Designing the fallback itself Whether the fallback raises or absorbs is a product decision, not a style one. Raising is right when the key set is closed and an unknown value means upstream sent something the exporter does not understand — better to stop than to write a partial, silently incomplete result. Absorbing is right when the key set is open by design and skipping is a legitimate outcome; then the fallback should still record what it skipped, with the key and enough identifying detail to find the record later, so the count of skips is a metric rather than a mystery. A third option is worth naming: validate the key set at startup rather than at dispatch. If the keys come from an `enum.Enum` or from a config file, you can check on load that every enum member has a handler, and turn a runtime dispatch miss into an import-time failure. That is the strongest version of the fallback question — the case that never reaches production. ## The shape to remember Look up, decide, then call. Everything that can go wrong with dispatch fallbacks comes from letting the call happen inside the construct that was meant to protect the lookup.