Why is it bad to rescue Exception?

You know exceptions?

They’re great – a really nice way of keeping your “happy code path” and “sad code path” separate. No more peppering your code with if statements, checking return values from everything you do. Instead stick a rescue clause in your method, specify which exceptions you are interested in and instant error handling!

But

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

Why is this?

As with everything else in Ruby, an Exception is an object.

This is particularly useful when defining your own exceptions – you can store any specific information you want by creating a sub-class and adding attributes for that data – then in your rescue clause, you handle that particular exception and examine your extra attributes.

But Exception is the root of that class hierarchy. So it has some very important subclasses that Ruby itself uses – SyntaxError, Interrupt, SignalException and other system-level stuff.

So

is a really bad idea. If there’s a SyntaxError (because do_something_with uses eval) then it will be silently eaten. If there’s an Interrupt then the operator won’t be able to use Ctrl-C to quit the app. If there’s a SignalException then the only way to quit the app will be to send a kill -9. Brute Force.

Instead, you should make your own exceptions subclass StandardError and use StandardError in your rescue clauses. This is so important, Ruby makes it easy for you:

I admit, I’m guilty of forgetting this one myself – especially in Rails where the framework handles the Interrupts and SignalExceptions for you.

But attention to detail is a hallmark of a good software developer, so make a promise to yourself that you will deal with this the right way and become a good Ruby citizen.