Forem: Taylor Kearns

Ruby to the Rescue

Taylor Kearns — Mon, 30 Jan 2023 21:42:09 +0000

TL;DR

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 StandardError.new("error") }.to raise_error

But we could get this test to pass:

expect { raise StandardError.new("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 {
  myFunction()
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
  do_the_work
rescue => error
  logger.error("There was an error: #{error}")
end

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:

Javascript

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

Ruby

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

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"
      throw(:goose)
    end
  end
end

$> 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
end

throw_rescue
$> uncaught throw StandardError

Theuncaught 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 StandardError.new("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:

Our Favorite Posts of 2022

Taylor Kearns — Fri, 30 Dec 2022 22:24:09 +0000

In 2022 we resumed meeting in person, we pumped the brakes on crypto, we watched the World Cup, we tried to purchase Taylor Swift tickets. And the software world kept spinning. Here at The Gnar we found we had a lot to say over the last year. Here are some examples of the work we've done and the words we've written during the last lap around the sun.

Code

Infinite Scroll React Example with TypeScript and NextJS

It's a matter of when - not if - you will be asked to implement infinite scroll. Here's a guide and example to get you (sc)rolling.

History Tracking with Postgres

A meaty piece on a rich topic. Postgres is a magical toolbox, and here we explore some of those tools in the context of preserving a history of transactions at the database level. This is part of the "Yeah, Postgres Can Do That" series, with another post going up in November. Check them both out!

Navigating Session Token Authentication in Shopify for Embedded, Server-Side Rendered Rails Apps

We've been spending a good amount of time in Shopify these days. And we of course build a lot of Rails apps. The authentication story for a Shopify store embedded in a server-side rendered Rails app is more complicated than you'd think. Read on to learn about how we addressed it.

Industry

What Is the Point of Free and Open Source Software?

In a pair of posts on free and open source software, we plumb the depths of software philosophy, business ethics, the common good, and where we currently find ourselves on the timeline of FOSS. Immersive, heady, and a lot of fun.

Make Yourself Accessible: Why it Matters

If you are concerned about accessibility (pro tip: you should be), start here. In the first of this three-part series, we discuss not only what accessibility means, but why it matters. In Parts Two and Three we get our hands dirty with testing, building accessibility into new applications, and adding accessibility to legacy applications.

Deconstructing Defi

For those who know something about crypto, something about blockchain, or a bit of both, this is a great way to dip your feet deeper into the pool. We illuminate the core concepts scaffolding Destructured Finance. Given the state of Defi today, this couldn't be more relevant.

Culture

Our Code Review Process: More than Quality Assurance

In this article we provide insight into the general code review process, and an overview of how it works at The Gnar. For those less familiar with the gears of software development, or for those looking to build a team, this can serve as a template. For those in the trenches, we hope you can take away some ideas about how to enhance your process.

Exploding Consulting Myths: Support

In a three-part series we call Exploding Consulting Myths, we demonstrate how culture at The Gnar is inclusive, supportive, and fun. In the conclusion of the series we enumerate the various support structures provided for our team, both technical and personal. A must-read if you are considering a new job (https://www.thegnar.com/about/join-our-team).

Hindsight Is 20/20

Taylor Kearns — Mon, 18 Oct 2021 13:01:54 +0000

Are you just starting to learn how to code? How exciting! And intimidating! No matter how long we've been in this business, we're always learning something new. The Gnar team discussed what basic advice we'd offer a developer at the beginning of the journey. Here's what we came up with.

It will probably take you two weeks to somewhat understand what you're being taught today. Don't freak out if you don't get it right away.
Read code every day. Just put your eyeballs on it, even if you don't understand it.
Error messages are your friend. They aren't shaming you, they are helping you target something to fix. Get comfortable reading error messages and don't be discouraged when you get them; be excited that there's a (hopefully helpful) starting point for your debugging.
Ask all of your questions, all of the time. If the answer doesn't make sense, it doesn't mean you were wrong for asking; it might mean that the question you had needs to be examined a little bit. Take the time to compare what you THINK you need to know, what the code is telling you, and what you're certain about. There may be information available to you that can lead you in a better direction. This is a skill that coders practice all the time, because we all feel lost on occasion. The trick is to find ways to feel confident that you do (or don't!) know something. That lets you learn it.
Use your tools. There are so many things that have been built to help you figure out what's going on in your code, and learning how to manipulate them will make it easier to learn new things and crack harder problems. Figure out how to use Inspector consoles, debugger statements, linters, editor features, terminal tricks, helper libraries, and (eventually) tests. Each language has a slightly different approach to these tools, but ultimately the goal's always the same: making the work you do easier and more enjoyable by creating ways around obstacles.
Try to build stuff on your own even if you think you're not very good yet. Exploring and practicing are the essence of being a dev. I've made so many different variations of to-do list apps just to keep me asking productive questions.
A large web framework essentially takes a string input and returns a different string output. Seeing a simplified example makes it easier to not be so overwhelmed by the entire framework.
When you get right down to it, code is simple. No magic, no elves, no wizards. Things are being compared, and the result of that comparison is either True or False. Learning to code is really about learning the basics of implementing these abstract flows in your mind, and then learning how to write and read them in code, in that order. This is why it is confusing - you have to conceptualize the solution in abstract logic, then work backwards to translate it into code. You may not be able to conceptualize how to build a pyramid, but at the end of the day it's a bunch of dried mud. I bet you can conceptualize dried mud.
YOU CAN UNDERSTAND THIS. Just give it time.

Contributors

Learn more about The Gnar and our team.

RSpec Negated Matchers

Taylor Kearns — Mon, 13 Sep 2021 01:26:21 +0000

Problem

We want to test that when we call our Ruby method, one result does occur while another result does not occur. Specifically, we want to test that an Event is created but that an EventPayload is not created. Using RSpec, we have this so far:

it "creates an event without an associated payload" do
  expect { service.create_event! }.to change { Event.count }.by(1)
  expect { service.create_event! }.not_to change { EventPayload.count }
end

This is ok, but we'd like to run both expectations on a single method call.

We know that RSpec has and which can help us make compound expectations, but this falls apart when we want to make one positive assertion and one negative assertion. We could try this:

it "creates an event without an associated payload" do
  expect { service.create_event! }
    .not_to change { EventPayload.count }
    .and change { Event.count }.by(1)
end

But no joy:

NotImplementedError: expect(...).not_to matcher.and matcher` is not supported, since it creates a bit of an ambiguity.

Solution

How can we chain two expectations together with and if one is a "not" condition? RSpec allows us to define a negated matcher:

RSpec::Matchers.define_negated_matcher :not_change, :change

Which allows us to then write this:

it "creates an event without an associated payload" do
  expect { service.create_event! }
    .to change { Event.count }.by(1)
    .and(not_change { EventPayload.count })
end

And we can flip the order if we choose:

it "creates an event without an associated payload" do
  expect { service.create_event! }
    .to not_change { EventPayload.count }
    .and change { Event.count }.by(1)
end

Fun!

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