rescue Exception is too broad
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
Exception is the root of the entire hierarchy, including SystemExit, NoMemoryError, and Interrupt. Rescuing it catches signals and fatal errors the process should not try to handle, which can make Ctrl-C or a deploy-time SIGTERM impossible to act on. Rescue StandardError, or a specific error class, instead.
Why it matters
rescue Exception catches everything, including SystemExit (raised when the process is asked to exit), NoMemoryError, SignalException, and Interrupt, not just application errors. A broad rescue like this can swallow a Ctrl-C or a deploy tool's termination signal, making the process difficult or impossible to stop cleanly when it matters most.
How to fix it
Change rescue Exception to rescue StandardError (Ruby's default when no class is given, and the ancestor of virtually every application-level error), or to the specific error class the code actually expects. Reserve catching Exception itself for the rare top-level supervisor process that genuinely needs to log everything before a controlled shutdown.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo