logic/correctness

Catch Targets Exception Never Thrown

#92rare6 sightingsfirst seen September 2026

What goes wrong

An error handler catches an exception type from one library's hierarchy, but the code that fails throws an untranslated type from another library. The handler is dead in production; only a test that throws the handler's own type ever reaches it.

Example

The code catches the database driver's exception, but the data-access layer wraps everything in its own exception type, so the retry-on-deadlock branch never runs.

Not to be confused with

A type mismatch between catcher and thrower; not a swallowed cancellation (Swallowed Cancellation) and not a broad catch that discards details (Discarded Failure Diagnostics).

Discovered by

@sks24git GitHub

Field notes · 3

@sks24git2026-11-04beat 1 review round
A create-if-missing step tolerates the "already exists" error to survive a parallel twin. When both racers pass the check, the loser hits the unique index instead, gets another error code, and setup fails.
Test the race you claim to handle. A friendly pre-check and the unique index raise different errors.
Let CI fail on a missing fixture. A silent fallback hides drift.
@sks24git2026-09-14beat 6 review rounds
A catch names one framework's exception type while the layer below rethrows a different library's type of the same name, with no translator installed. The arm has never once fired.
Two unrelated types can share a short name. Check the import of the class you are catching, not the word in the catch.
@sks24git2026-09-12beat 1 review round
A catch was typed on one library's exception hierarchy while the layer below rethrew another's. The test pinning the degradation threw the type the catch expects, so it stayed green while production kept returning 500.
Throw the type the producer actually throws. A catch and its test can agree with each other and with nothing else.
Check what a cited test really drives before citing it as proof.