Turn rescue _ -> fallback into rescue _ in [ExceptionType1, ExceptionType2] -> fallback\nso programmer bugs propagate while known failure modes stay handled.
Bare rescues (rescue _ ->, rescue e -> — any form without an in clause) swallow\nevery exception, including UndefinedFunctionError from typos, KeyError from\nmisspelled map keys, and CompileError from bad HEEx templates. The symptom isn't a stack\ntrace — it's a silent {:error, :generic} or a nil fallback. Bugs that should surface\nin tests or error reporters become quiet degradations.
The Erlang Secure Coding Guide makes\nthe same case at the BEAM level — rule LNG-002 (\"Do Not Use catch\") warns that the\nlegacy catch-all form conflates normal returns, throws, and errors. Bare rescue in Elixir\nis the direct analogue.
rescue _ -> or rescue e -> without an in clause. Every rescue must\nlist exact exception types. The Credo check enforces this after cleanup lands.UndefinedFunctionError,\nCompileError, BadFunctionError, and BadArityError must propagate.reraise e, __STACKTRACE__, never reraise e, []. Preserve the original stack\ntrace so Oban retry metadata and error reporters show the real origin.mix compile --warnings-as-errors before committing. Typos in exception module\nnames only surface at compile time — the code looks fine until it loads.# Before — masks programmer bugs\ndef parse(body) do\n Jason.decode!(body)\nrescue\n _ -> %{}\nend\n\n# After — catches only what can actually fail here\ndef parse(body) do\n Jason.decode!(body)\nrescue\n _ in [Jason.DecodeError, ArgumentError] -> %{}\nend\nApplies identically to try … rescue … and to function-body def … rescue ….
The skill operates in three modes depending on scope:
\n/narrow-bare-rescue path/to/file.ex/narrow-bare-rescue lib/my_app/util//narrow-bare-rescue --allWhatever the scope, follow this sequence.
\ngrep -rn \"^\\s*rescue\\s*$\" <scope> | head -200\nFor each hit, read the 3 lines after to classify:
\nrescue _ -> or rescue var -> — bare, needs narrowingrescue _ in [...] -> or rescue var in Something -> — already typed, skiprescue ExceptionType -> (no variable binding) — already typed, skipRead the try / def body and trace what each call can raise. Don't guess from the\nfunction name — verify. Consult order:
Check references/taxonomy.md for the work type (JSON, Ecto, Money, HTTP, etc.).\nMost sites map cleanly to one row.
Grep deps for defexception when a specific library isn't in the taxonomy:
grep -rn \"defexception\" deps/<libname>/lib/ | head -10\nCheck raise calls in the code path itself — if the body explicitly raises\nRuntimeError, include it.
Priorities: cover everything the code can actually raise, exclude programmer-bug\nexceptions (see Iron Law #3), and prefer specific types (Jason.DecodeError beats\nArgumentError if both could apply).
For files with ≥3 rescues sharing a taxonomy, hoist to a module attribute — see\nreferences/patterns.md for the module-attribute pattern, Oban reraise, ExCmd exit\nerrors, and is_exception/1 replacements.
After changes in each file (or cluster of files), run:
\nmix compile --warnings-as-errors\nmix format <files_changed>\nmix test <test_files_for_affected_modules>\nThe compile step catches typos in exception module names — a real risk since you're writing\nmodule names from memory.
\nThis skill narrows bare rescue clauses. It does not:
rescue e in [X] ->) — those are correctcatch clauses — throws and exits from the process are a separate concerntry/rescue with with or error-tuple plumbing — that's a larger refactorreferences/taxonomy.md — verified exception types per work\ncategory, plus library-specific gotchas (NimbleCSV, Plug, Phoenix LiveView tokenizer)references/patterns.md — special patterns: is_exception/1,\nOban reraise, ExCmd exit errors, module-attribute hoisting, partitioning large\ncleanups, the regression-prevention Credo checkcatch\n— BEAM-level rationale for preferring narrow try ... catch / try ... rescue over\nthe legacy catch-all form