Ruby to the Rescue for Error Handling

  • January 27, 2023
  • Taylor Kearns
  • 4 min read


Though we frequently use the terms "throw" and "catch" when discussing error handling, we must be careful in Ruby to use the more accurate terms "raise" and "rescue". "Throw" and "catch" have a significantly different meaning in Ruby.

The Problem

The other day we were writing an RSpec test and were surprised to find that we couldn't get this test to pass:

expect { throw"error") }.to raise_error

But we could get this test to pass:

expect { raise"error") }.to raise_error

Aren't these basically the same thing, with a minor syntactic difference? Raise an error, throw an error, same idea right? In Javascript we use try..catch for handling errors. Isn't it the same idea with Ruby? Not really. Ruby has two similar looking statements: try..catch and raise..rescue. Even though we can technically use each of these statements in similar situations and get ostensibly similar results, the intent behind the two structures is quite different.

In Ruby, Don't Catch Errors; Rescue Them

The main source of confusion (for me, anyway) is in the term catch. When I think catch, I think error. In Javascript if we want to handle an error we write something like:

try {
catch (error) {
  console.error(`There was an error: ${error}`)

So in Ruby wouldn't I do something similar? Yes, but not with try..catch. In Ruby we use raise..rescue.

def my_function
rescue => error
  logger.error("There was an error: #{error}")

Ruby's raise..rescue is the corollary to Javascript's try..catch. If we compare the complete syntax of both structures, especially when we employ the optional begin keyword, the patterns look even more similar:


try {
  // do stuff
catch {
  // catch the error
finally {
  // do this no matter what


  # do stuff
rescue => e
  # catch the error
  # do this no matter what

So what is catch for in Ruby, if not for errors?

The throw..catch statement in Ruby is actually intended to be used as a part of an expected workflow rather than for an exceptional (i.e. error) scenario. throw..catch can be used as a means of escaping from a flow once a particular requirement is met. In the example below, we have an array of birds. As soon as we find a goose, we want to stop execution of the each loop. This example is contrived, but we can imagine that if we were performing expensive procedures in each iteration, we would want to bail out as soon as we are able.

birds = ["duck", "duck", "goose", "duck"]

catch(:goose) do
  birds.each do |bird|
    puts bird

    if bird == "goose"

$> duck
$> duck
$> goose

catch is meant to be used with throw, and likewise throw is meant to be used with catch. Though we may see code in the wild in which an error is thrown and later rescued, that's not really what it's intended for. In fact if you try that out, take a look at the error message.

def throw_rescue
  throw StandardError, "There was an error."
rescue => e
  puts e
$> uncaught throw StandardError

The uncaught throw tells us explicitly that we should be using catch somewhere. Additionally, look what we're missing: a stacktrace. Because throwing and catching are meant to be part of an expected flow, it makes sense that they wouldn't have a a stacktrace. So in this case we get a misleading exception (uncaught throw vs. StandardError) and no additional information about the source of the error.

What makes this even more confusing is that we can throw more than just symbols. As we see above, we can throw class names, like Exceptions. But we really shouldn't, as the example above should demonstrate.

Looking back at our original question about our RSpec test, we can see now why this test won't ever pass:

expect { throw"error") }.to raise_error

We can't expect throwing an error to raise that error, because throwing and raising aren't the same thing in Ruby. If you want to handle errors, do so with raise..rescue, not try..catch.

Here are some additional resources on raise..rescue and throw..catch:

Learn more about how The Gnar builds Ruby on Rails applications.


If you liked this article please subscribe to our newsletter

Be assured that we will not sell, trade or otherwise share your information with any other party.

Interested in building with us?