Exceptions are control flow, and unhandled control flow is a bug. The two failure modes are equally bad: a top-level uncaught exception crashes the process and can lose in-flight work, while an over-broad catch (except Exception:, catch (e) with no rethrow) swallows the error and lets the program continue in an inconsistent state.
Specific bugs in this family: an async function that rejects and no .catch is attached (Node logs an UnhandledPromiseRejection and may exit), a worker that catches all exceptions and acks the message anyway (silent data loss), a UI handler that throws and the framework dies showing an unstyled error page.
The defense is to be deliberate about every catch: catch the *specific* exceptions you expect, log with enough context to debug, and rethrow or fail loudly when you're not sure. Top-level handlers exist to convert exceptions to user-friendly errors, not to make problems disappear.
Review heuristic
Every catch block should answer two questions in the diff or in a comment: which specific exceptions am I handling, and what do I do with the rest? catch (e) {} is the smoking gun; except: pass is its Python cousin.
External reference
CWE-248: Uncaught Exception — the canonical industry classification for this bug class. Useful when filing tickets, writing security policies, or arguing with a static analyzer.