---
title: How to raise any object as a Ruby exception
published: "2015-08-04"
publisher: Honeybadger
author: Starr Horne
category: Ruby articles
tags:
  - Ruby
description: "It's a common misconception that the raise method only accepts exceptions as its argument. This post will show you how you can raise ANYTHING, including numbers, dates, and your own custom classes."
url: "https://www.honeybadger.io/blog/how-to-raise-any-object-as-a-ruby-exception/"
---

Ruby's raise syntax gives you a couple of options for specifying the kind of error you want raised. In the code below, I've shown three ways to raise a RuntimeError.

```ruby
raise "hello" raise RuntimeError, "hello" raise RuntimeError.new("hello") # ...all of the above result in "RuntimeError: hello"
```

That's nice, but what happens when I want to raise something other than an exception? What if I wanted to raise a number? Well, Ruby won't let me. I'd get an error message like this:

```ruby
raise 1 # TypeError: exception class/object expected
```

Now this message might lead you to believe that raise expects an exception class/object as a parameter. But that's incorrect!

## Introducing the `exception` method

If you do `raise foo` the raise method doesn't expect foo to be an exception object. It expects that it will get an exception object whenever it calls `foo.exception`.

The thing to remember is that you can pass ANYTHING to raise, just as long as it has a method called exception that returns an exception.

So, if you wanted to, you could monkeypatch ruby's number classes to allow you to raise a number. Here's what that might look like:

```ruby
class Fixnum def exception RuntimeError.new("I'm number: #{ self }") end end raise 42 # ...results in raise_number.rb:7:in `<main>': I'm number: 42 (RuntimeError)
```

This is a neat party trick, but could it ever be useful in real life? The main practical application I see for this technique is to separate the logic required to build an exception from the logic that decides to raise the exception. This is certainly a bit of an edge case. But let's see what that might look like.

## A possibly practical example

Suppose I want to read a line of data from some kind of IO. It could be network IO, it could be a file. It doesn't really matter. I just want to read the data and see if it's valid.

If the data I read isn't valid, I want to raise an exception. But the exception needs to be tailored to the input. A network connection needs to have different debug info than a local file. I can do that by providing custom exception methods for each kind of input class. Here's some pseudo-ruby showing what that might look like.

```ruby
# These three classes represent different kinds of IO with different exceptions. class NetworkConnection ... def exception NetworkConnectionError.new(url: url, ...) end end class LocalFile ... def exception FileError.new(path: path, ...) end end class UnixPipe ... def exception PipeError.new(...) end end def read_all(*items) items.each do |item| if item.readline != "foo" # We raise the item, which causes the appropriate exception class to be used. raise item end end end read_all(NetworkConnection.new(url: "example.com"), LocalFile.new("/something"), UnixPipe.new)
```

---

## Try Honeybadger for FREE

Intelligent logging, error tracking, and Just Enough APM™ in one dev-friendly platform. Find and fix problems before users notice.

[Start free trial](https://app.honeybadger.io/users/sign_up)

[See plans and pricing](https://www.honeybadger.io/plans/)