narrow-bare-rescue

Narrow Bare Rescue

Turn rescue _ -> fallback into rescue _ in [ExceptionType1, ExceptionType2] -> fallback

so programmer bugs propagate while known failure modes stay handled.

Why this matters

Bare rescues (rescue _ ->, rescue e -> — any form without an in clause) swallow

every exception, including UndefinedFunctionError from typos, KeyError from

misspelled map keys, and CompileError from bad HEEx templates. The symptom isn't a stack

trace — it's a silent {:error, :generic} or a nil fallback. Bugs that should surface

in tests or error reporters become quiet degradations.

The Erlang Secure Coding Guide makes

the same case at the BEAM level — rule LNG-002 ("Do Not Use catch") warns that the

legacy catch-all form conflates normal returns, throws, and errors. Bare rescue in Elixir

is the direct analogue.

Iron Laws

1. Never leave rescue _ -> or rescue e -> without an in clause. Every rescue must

list exact exception types. The Credo check enforces this after cleanup lands.

1. Cover every exception the code path can actually raise. Narrowing that drops a real

exception is a behavioral regression — trace each call in the body before committing.

1. Never include programmer-bug exceptions in the list. UndefinedFunctionError,

CompileError, BadFunctionError, and BadArityError must propagate.

1. Use reraise e, __STACKTRACE__, never reraise e, []. Preserve the original stack

trace so Oban retry metadata and error reporters show the real origin.

1. Run mix compile --warnings-as-errors before committing. Typos in exception module

names only surface at compile time — the code looks fine until it loads.

The core transform

# Before — masks programmer bugs
def parse(body) do
  Jason.decode!(body)
rescue
  _ -> %{}
end

# After — catches only what can actually fail here
def parse(body) do
  Jason.decode!(body)
rescue
  _ in [Jason.DecodeError, ArgumentError] -> %{}
end

Applies identically to try … rescue … and to function-body def … rescue ….

Workflow

The skill operates in three modes depending on scope:

1. Single file — /narrow-bare-rescue path/to/file.ex
2. Directory — /narrow-bare-rescue lib/my_app/util/
3. Whole project — /narrow-bare-rescue --all

Whatever the scope, follow this sequence.

Step 1 — Find the sites

grep -rn "^\s*rescue\s*$" <scope> | head -200

For each hit, read the 3 lines after to classify:

• rescue _ -> or rescue var -> — bare, needs narrowing
• rescue _ in [...] -> or rescue var in Something -> — already typed, skip
• rescue ExceptionType -> (no variable binding) — already typed, skip

Step 2 — Determine the exception set for each bare site

Read the try / def body and trace what each call can raise. Don't guess from the

function name — verify. Consult order:

1. Check ${CLAUDE_SKILL_DIR}/references/taxonomy.md for the work type (JSON, Ecto, Money, HTTP, etc.).

Most sites map cleanly to one row.

1. Grep deps for defexception when a specific library isn't in the taxonomy:

   grep -rn "defexception" deps/<libname>/lib/ | head -10

1. Check raise calls in the code path itself — if the body explicitly raises

RuntimeError, include it.

Priorities: cover everything the code can actually raise, exclude programmer-bug

exceptions (see Iron Law #3), and prefer specific types (Jason.DecodeError beats

ArgumentError if both could apply).

Step 3 — Apply the narrowing

For files with ≥3 rescues sharing a taxonomy, hoist to a module attribute — see

${CLAUDE_SKILL_DIR}/references/patterns.md for the module-attribute pattern, Oban reraise, ExCmd exit

errors, and is_exception/1 replacements.

Step 4 — Verify

After changes in each file (or cluster of files), run:

mix compile --warnings-as-errors
mix format <files_changed>
mix test <test_files_for_affected_modules>

The compile step catches typos in exception module names — a real risk since you're writing

module names from memory.

Scope

This skill narrows bare rescue clauses. It does not:

• Auto-narrow blindly — behavior preservation matters; trace each call path first
• Touch rescues that are already typed (rescue e in [X] ->) — those are correct
• Cover catch clauses — throws and exits from the process are a separate concern
• Replace try/rescue with with or error-tuple plumbing — that's a larger refactor

References

• ${CLAUDE_SKILL_DIR}/references/taxonomy.md — verified exception types per work

category, plus library-specific gotchas (NimbleCSV, Plug, Phoenix LiveView tokenizer)

• ${CLAUDE_SKILL_DIR}/references/patterns.md — special patterns: is_exception/1,

Oban reraise, ExCmd exit errors, module-attribute hoisting, partitioning large

cleanups, the regression-prevention Credo check

• Erlang Secure Coding Guide — LNG-002: Do Not Use catch

— BEAM-level rationale for preferring narrow try ... catch / try ... rescue over

the legacy catch-all form