Understanding the Ruby Exception Hierarchy

In this post we look at Ruby's exception class heirarchy, and how you can use it to be as broad or as narrow as you like when rescuing exceptions.

Exceptions are just classes in Ruby. The exception exception hierarchy is made up of all the classes that inherit from Exception.

Here's a the exception hierarchy for Ruby 2.1's standard library.

Exception
  NoMemoryError
  ScriptError
    LoadError
    NotImplementedError
    SyntaxError
  SecurityError
  SignalException
    Interrupt
  StandardError -- default for rescue
    ArgumentError
      UncaughtThrowError
    EncodingError
    FiberError
    IOError
      EOFError
    IndexError
      KeyError
      StopIteration
    LocalJumpError
    NameError
      NoMethodError
    RangeError
      FloatDomainError
    RegexpError
    RuntimeError -- default for raise
    SystemCallError
      Errno::*
    ThreadError
    TypeError
    ZeroDivisionError
  SystemExit
  SystemStackError

Practical uses

The reason that exceptions are arranged into a class tree is so that you can easily rescue similar types of exception.

For example, consider the code:

begin
  do_something
rescue StandardError => e
end

This will rescue not only StandardError, but also any exception that inherits from it. That happens to be pretty much any exception you'll be interested in.

In your own code, you might have all of your custom exceptions inherit from a single base class:

module MyLib

  class Error < StandardError
  end

  class TimeoutError < Error
  end

  class ConnectionError < Error
  end

end

...

begin
  do_something
rescue MyLib::Error => e
  # Rescues any of the exceptions defined above
end


What to do next:
  1. Try Honeybadger for FREE
    Honeybadger helps you find and fix errors before your users can even report them. Get set up in minutes and check monitoring off your to-do list.
    Start free trial
    Easy 5-minute setup — No credit card required
  2. Get the Honeybadger newsletter
    Each month we share news, best practices, and stories from the DevOps & monitoring community—exclusively for developers like you.
    author photo

    Starr Horne

    Starr Horne is a Rubyist and Chief JavaScripter at Honeybadger.io. When she's not neck-deep in other people's bugs, she enjoys making furniture with traditional hand-tools, reading history and brewing beer in her garage in Seattle.

    More articles by Starr Horne
    Stop wasting time manually checking logs for errors!

    Try the only application health monitoring tool that allows you to track application errors, uptime, and cron jobs in one simple platform.

    • Know when critical errors occur, and which customers are affected.
    • Respond instantly when your systems go down.
    • Improve the health of your systems over time.
    • Fix problems before your customers can report them!

    As developers ourselves, we hated wasting time tracking down errors—so we built the system we always wanted.

    Honeybadger tracks everything you need and nothing you don't, creating one simple solution to keep your application running and error free so you can do what you do best—release new code. Try it free and see for yourself.

    Start free trial
    Simple 5-minute setup — No credit card required

    Learn more

    "We've looked at a lot of error management systems. Honeybadger is head and shoulders above the rest and somehow gets better with every new release."
    — Michael Smith, Cofounder & CTO of YvesBlue

    Honeybadger is trusted by top companies like: