Ruby DISCUSSION

Why is rescue Exception considered bad practice in Ruby, and what should I rescue instead?

Started by ahmedalhazemi Ruby rescue ExceptionStandardErrorexception hierarchyretry and ensureInterrupt handling
4 replies 248 views 5 participants
Latest activity · 30 Sep 2026

Why is rescue Exception considered bad practice in Ruby, and what should I rescue instead?

ahmedalhazemi Ruby Forum
#1

My data logger script wraps its main loop in begin ... rescue Exception => e so that it keeps running whatever happens, logging the error and continuing. Now Ctrl+C no longer stops it and I have to kill the process. A linter also flags the line and says to avoid rescuing Exception.

What is wrong with catching everything, what does a bare rescue catch, and how should a long-running script handle errors so that it survives failures but can still be stopped?

Community replies 4

Re: Why is rescue Exception considered bad practice in Ruby, and what should I rescue instead?

#2

Exception is the root of the whole hierarchy, and some of its branches are not errors in your code at all. Ctrl+C arrives as Interrupt, a termination signal as SignalException, a call to exit as SystemExit; there are also NoMemoryError, SystemStackError and ScriptError (which includes SyntaxError and LoadError).

Rescuing Exception swallows all of these, so your loop catches the interrupt, logs it and carries on. That is why the script cannot be stopped.

Re: Why is rescue Exception considered bad practice in Ruby, and what should I rescue instead?

#3

Ordinary, recoverable errors all descend from StandardError: ArgumentError, IOError, ZeroDivisionError, RuntimeError, the Errno system-call errors and so on. A bare rescue and rescue => e both mean rescue StandardError, so the smallest fix is to delete the word Exception. Ctrl+C then works again.

Your own error classes should inherit from StandardError for the same reason: class SensorTimeout < StandardError; end. A class that inherits directly from Exception slips past every bare rescue.

Re: Why is rescue Exception considered bad practice in Ruby, and what should I rescue instead?

#4

Better still, rescue the specific things you know how to handle, close to where they occur: rescue Errno::ENOENT, IOError => e around the port access. StandardError includes NoMethodError and NameError, so a blanket rescue also hides typos and nil bugs and leaves the loop quietly doing nothing useful.

For transient faults, bound the retries: keep a counter, and in the rescue clause do attempts += 1, then if attempts < 3 sleep half a second and retry, otherwise raise. Three attempts with 0.5 s pauses cost about one extra second before the error is reported, instead of looping forever.

Re: Why is rescue Exception considered bad practice in Ruby, and what should I rescue instead?

#5

For cleanup and for stopping cleanly, use ensure and handle the interrupt on purpose. Code in an ensure clause runs whether the block finishes, raises or is interrupted, so that is where the port and the log file get closed. If you want a tidy message on Ctrl+C, add a separate rescue Interrupt at the outermost level that prints it and lets the program end.

There is one legitimate use of rescue Exception: a top-level handler that logs the failure and then re-raises with a bare raise. Logging and re-raising loses nothing; swallowing is the problem. Also avoid the inline modifier form value = risky_call rescue nil, since it silently discards every StandardError.

TEP COMMUNITY