Why is it bad style to `rescue Exception => e` in Ruby?

Ryan Davis’s Ruby QuickRef says (without explanation):

Don’t rescue Exception. EVER. or I will stab you.

Why not? What’s the right thing to do?

 

Exception is the root of Ruby's exception hierarchy, so when you rescue Exception you rescue from everything, including subclasses such as SyntaxError, LoadError, and Interrupt.

Rescuing Interrupt prevents the user from using CTRLC to exit the program.

Rescuing SignalException prevents the program from responding correctly to signals. It will be unkillable except by kill -9.

Rescuing SyntaxError means that evals that fail will do so silently.

All of these can be shown by running this program, and trying to CTRL+C or kill it:

 

loop do
begin
sleep 1
eval "djsakru3924r9eiuorwju3498 += 5u84fior8u8t4ruyf8ihiure"
rescue Exception
puts "I refuse to fail or be stopped!"
end
end

 

Rescuing from Exception isn't even the default. Doing

 

 

begin
# iceberg!
rescue
# lifeboats
end

 

does not rescue from Exception, it rescues from StandardError. You should generally specify something more specific than the default StandardError, but rescuing from Exception broadensthe scope rather than narrowing it, and can have catastrophic results and make bug-hunting extremely difficult.

 

If you have a situation where you do want to rescue from StandardError and you need a variable with the exception, you can use this form:

 

begin
# iceberg!
rescue => e
# lifeboats
end

 

which is equivalent to:

begin
# iceberg!
rescue StandardError => e
# lifeboats
end

 

One of the few common cases where it’s sane to rescue from Exception is for logging/reporting purposes, in which case you should immediately re-raise the exception:

begin
# iceberg?
rescue Exception => e
# do some logging
raise e # not enough lifeboats ;)
end

 

--------------------------------------------------------------------------------------

so it's like catching Throwable in java – ratchet freak Apr 7 '12 at 0:15

@Excalibur If you’re re-raising the exception, then it’s fine since you’re not swallowing it, but just trying to know that it happened then letting it bubble up. Usually done for logging. 

OK, that's like best answer ever on SO. – Dan Barron Sep 16 at 20:53

This advice is good for a clean Ruby environment. But unfortunately a number of gems have created exceptions that directly descend from Exception. Our environment has 30 of these: e.g. OpenID::Server::EncodingError, OAuth::InvalidRequest, HTMLTokenizerSample. These are exceptions that you'd very much want to catch in standard rescue blocks. Unfortunately, nothing in Ruby prevents or even discourages gems from inheriting directly from Exception -- even the naming is unintuitive. – Jonathan Swartz Sep 19 at 17:08
@JonathanSwartz Then rescue from those specific subclasses, not Exception. More specific is nearly always better and clearer. – Andrew Marshall Sep 19 at 19:15
Andrew - there are many times you want to catch all standard exceptions. You mentioned one yourself - if you want to add some context to the message, then rethrow or log or airbrake it.