» Making a Strong Argument
Ruby’s ArgumentError is raised when you call a method with incorrect arguments. There are several ways in which an argument could be considered incorrect in Ruby:
- The number of arguments (arity) is wrong
- The value of the argument is unacceptable
- The keyword is unknown when using keyword arguments
Because Ruby itself uses ArgumentError in these conditions, many Ruby developers extend the pattern when building their own methods.
For example, say that you have a list of creatures and want to print the most popular:
CREATURES = ['NoMethodError', 'TypeError', 'ArgumentError', 'RuntimeError']
def top(n)
puts CREATURES[0...n]
end
top(2) # =>
# NoMethodError
# TypeError
Since there are 4 creatures, calling top with an argument up to 4 will print 4 values. However, what happens when we call top with an argument of 5?
top(5) # =>
# NoMethodError
# TypeError
# ArgumentError
# RuntimeError
Since there are 4 values in the array, 4 are printed. This could be confusing if our calling code is expecting 5 values. Let’s make our method raise an exception when the argument is larger than the total number of values in the array:
def top(n)
raise ArgumentError.new(
"Expected a value of 1-#{CREATURES.size}, got #{n}"
) if CREATURES.size < n
puts CREATURES[0...n]
end
Now, when we call top(5), we get a helpful error telling us exactly what we did wrong:
top(5) # => ArgumentError: Expected a value of 1-4, got 5
What happens if you call the top method with zero, or a negative value? If you’re new to ruby, try extending top to raise ArgumentError for these exceptional cases!
» Argument vs. Parameter: Did You Know?
You may have seen the terms argument and parameter used (seemingly) interchangeably when discussing method definitions. That’s because there is a slight distinction between these two terms! Let’s revisit our top method:
def top(number)
puts CREATURES[0...number]
end
The word number on the first line of the method definition is called a parameter. It hasn’t been used to call the method yet. Now, say you want to call the method you’ve created:
The value 100 that you’re passing to the top method is called an argument.
Ruby Errors
Objectives
Understand how to read Ruby error messages and use them to fix programs and build programs.
Introduction
So far, we’ve been introduced to some common errors and learned to read and understand error messages that appear as a consequence of running Ruby programs and test suites. This lesson provides a closer look at some common types of errors. Right now, it may be the case that not all of these error messages make sense or seem meaningful to you. After all, we’ve only handled a few real programs at this point.
This is meant to be a resource for you to refer back to as you start building more complex programs and have to debug them. There are a few important take-aways from this and the previous two lessons:
-
Don’t be afraid of broken programs! It’s easy to get frustrated when your program breaks. The tendency of a lot of beginners is to jump right back into the code when a test fails or an error comes up as a consequence of running a program, without reading the error messages. Error messages are there to guide you. They contain important information about the location and type of problem you are encountering. Embrace them and get comfortable reading them––don’t run away from them.
-
Pay attention to the helpful part of error messages. Check out the line number and the type of error that you’re receiving. This will point you in the right direction. Let’s take a look at an example from an earlier lab.
Failures: 1) Not having any errors and being all green ZeroDivisionError raises a ZeroDivisionError for dividing by zero Failure/Error: expect{ expected no Exception, got #<TypeError: nil can't be coerced into Fixnum> with backtrace: # ./lib/a_division_by_zero_error.rb:3:in `/' # ./lib/a_division_by_zero_error.rb:3:in `<top (required)>' # ./spec/no_ruby_errors_spec.rb:30:in `load' # ./spec/no_ruby_errors_spec.rb:30:in `block (4 levels) in <top (required)>' # ./spec/no_ruby_errors_spec.rb:29:in `block (3 levels) in <top (required)>' # ./spec/no_ruby_errors_spec.rb:29:in `block (3 levels) in <top (required)>'
This is some of the output we received after running our test suite with the learn or rspec command on this lab. There is a lot going on there! BUT––we know what to look for now.
We pay attention to the text right after the Failure/Error:.
It reads: expect{ expected no Exception, got #<TypeError: nil can't be coerced into Fixnum>
Now we know we are dealing with a TypeError and that something in our program is nil. But what? Well, let’s take a look at the next line: # ./lib/a_division_by_zero_error.rb:3:in/’`
That is telling us that our error is likely originating on line 3 of this file, lib/a_division_by_zero_error.
The rest of the error message is very likely just noise.
Error Types
Name Errors
NameErrors are caused when a given name is invalid or undefined. Whenever the Ruby interpreter encounters a word it doesn’t recognize, it assumes that word is the name of a variable or a method. If that word was never defined as either a variable or a method, it will result in a name error.
Syntax Errors
Syntax errors are pretty self explanatory: they’re the result of incorrect syntax. Thankfully, they’re usually followed by a guess about the location of the error. For instance:
Will result in:
2: syntax error, unexpected end-of-input, expecting keyword_end
Here, Ruby is saying that on line 2, there is a missing end (every do keyword must be followed by some code and then an end keyword). Always read the full details of syntax errors and look for line numbers, which usually appear at the beginning of the error message.
No Method Errors
Let’s say you want to calculate the amount that each coworker owes for a lunch order on Seamless. The order came to $64.25 for you and your three coworkers and you all agreed to split the total evenly so you write:
total = "64.25" num_of_people = 4 price_per_person = total / num_of_people
And you get:
3:in `<main>': undefined method `/' for "64.25":String (NoMethodError)
This error happened because you defined total as a string, not as a number, and Ruby doesn’t know how to divide a string by a number. It’s like telling Ruby to divide the word «lemon» by 7—it has no idea what to do. There are two ways around this error:
- Option One: You could change
totalinto a float from the start by removing the quotes:
total = 64.25 num_of_people = 4 price_per_person = total / num_of_people # => 16.0625
- Option Two: You could change
totalfrom a string to a float in the division step:
total = "64.25" num_of_people = 4 price_per_person = total.to_f / num_of_people # => 16.0625
The NoMethodError will often occur when you have a variable set to nil (essentially, nothing or no value), without realizing it. Most attempts to use a method on something that equals nil will result in the NoMethodError. This is because you are asking an object, nil in this case, to do something it does not know how to do. In other words, you are calling a method that is not defined for that particular object.
For example:
missing_value = nil missing_value.length
This will produce the following error
NoMethodError: undefined method `length' for nil:NilClass
Argument Errors
Argument errors occur when methods are passed either too few or too many arguments. For instance, let’s say you have a simple method, called calculate_interest which takes the value of a loan and finds the amount of interest that accumulates over the loan’s first year given that the annual interest rate is 5.25%:
def calculate_interest(loan_amount) loan_amount * 0.0525 end
You want to see what happens so you call it below:
def calculate_interest(loan_amount) loan_amount * 0.0525 end puts calculate_interest
What results is:
1:in `calculate_interest': wrong number of arguments (0 for 1) (ArgumentError)
This is because you called on the method calculate_interest which takes one argument, loan_amount, without passing it a value for loan_amount. To call on this method, you must pass it a number. For instance, let’s say you’re considering taking out a loan of $9,400 to buy a fancy La Marzocco espresso machine for your cafe.
def calculate_interest(loan_amount) loan_amount * 0.0525 end puts calculate_interest(9400)
Now that you passed the method a value for loan_amount, it will calculate the first year’s interest, $493.50.
TypeErrors
When you try and do a mathematical operation on two objects of a different type, you will receive a TypeError. For example if you try and add a string to an integer, Ruby will complain.
Will produce the following error:
TypeError: String can't be coerced into Fixnum
Another common TypeError is when you try and index into an array with a variable that doesn’t evaluate to an integer.
index = "hello" array = [1,2,3] array[index]
Will produce the following error:
TypeError: no implicit conversion of String into Integer
Ruby is telling you that it is trying to convert the string you passed as the index to the [] method into an integer, but it can’t.
Conclusion
There are many other errors that can occur in Ruby, this just covered the most common errors encountered when beginning to code in Ruby. Ruby errors are pretty descriptive and they are there to help you out, so always see if the error is offering you a hint about your code.
View Ruby Errors on Learn.co and start learning to code for free.
View Debugging Errors in your Ruby Code on Learn.co and start learning to code for free.
So you’ve decided to learn how to code. The first thing you need to know about this road you’ve started down is that programming is awesome. Let me repeat that, just to make sure you heard me. Programming is really, really awesome. You may have already built a program that outputs “Hello, World!” to your terminal. If so, you’ve experienced feelings of joy at seeing a program you wrote yourself work properly. Know that that feeling pales in comparison to the feeling you’ll have when you build your first complex application from empty file to finished product. If your experience is like mine, that will be the moment you fall hopelessly in love with code.
But before I let my romanticism lead me off topic, there’s something else you should know about programming. It’s hard. Let me repeat that, just to make sure you heard me. Programming is really, really hard. One of the hardest things about it, I think, especially for the total beginner, is errors. You’ll see error messages way more often than you’ll see your code actually working, so learning to read and understand them is an essential skill that you have to develop. I struggled to understand error messages for the first several months of my programming journey. But when someone finally taught me how to read them, it completely changed my world. Debugging was so much easier (and more fun), and I started to become less frustrated. So I’m writing this for you, dear code newbie, because I wish someone had written something like this for me when I started. We’re going to talk about what errors are, the five most common errors you’ll encounter, what the errors mean, and how to resolve them. I won’t be able to tell you how to deal with every situation in which you might see these errors, but I’ll try and give you a basic framework to work with.
Quick aside: please bear with me if my examples seem a bit contrived. I’m using simple scenarios to explain error messages, even though the code might be unrealistic.
WHAT ARE ERRORS?
Ruby will throw, or raise, an error when something in your program is not working properly. Error messages are your interpreter telling you that something needs to be fixed. If you don’t know what I mean by «interpreter», don’t worry so much about it now. It’s beyond the scope of this post, but just understand that it has to do with how your code is read and executed in your computer. (If you’re dying to know more, Google around, but finish reading this first).
Write this down on a Post-it and stick it next to your computer: errors are not setbacks, they’re opportunities. When your program throws an error, it doesn’t mean that you’re a bad programmer. I think that many of us in the beginning stages feel that if we were better at programming we could build an application and see minimal errors. Thinking this way will only lead to misery, so the first thing you need to realize is that errors are normal. Your program won’t be transmitted from your brain to your text editor in flawless form with awe-inspiring functionality. It will start broken, and require you to fix it. This is the fun part about programming, believe it or not. This is where you get to solve problems and gain the satisfaction that comes from that. And that’s what errors are there for. Errors are your friend, not your foe. Listen to them. They want to help you. Frustration is normal, but always remember that running into errors does not mean you’re a bad programmer. Instead, read on, and learn how to use them to your advantage.
HOW DO I READ AN ERROR MESSAGE?
Error messages give you three key pieces of information, the “where”, the “why”, and the “what”.
A typical error message looks like this:
lib/my_file.rb:32::undefined local variable or method `some_variable' for main:Object (NameError)
lib/my_file.rb:32 tells you that the error occurred in the lib directory, in the file my_file.rb, on line 32 of that file. That’s the «where».
undefined local variable or method `some_variable' tells you what went wrong. In this case, that Ruby found a local variable or method it didn’t recognize, and it needs to be defined. That’s the «why».
(NameError) tells you the type of exception Ruby raised. In this case, a NameError. You got it, that’s the «what».
The most important piece of advice I can give you is to always read the whole error. When you’re debugging, you’re a detective and you need all the clues you can find. First, find out where the error occurred, and go to that line. Read that line of code, and all the lines immediately preceding and following it. Are there any other methods that call the one where the error occurred? Read those too. Once you do that, you can read the rest of the error message, and find out why the error was thrown, and what error it is. Suddenly you are no longer blindly trying to debug your code, but you have some perspective. You have information that you can use to figure out exactly what went wrong.
Let’s start with this one, and talk about a few other common errors you’ll encounter.
NameError
What the what?
Generally, this error is raised when you call a variable or method that Ruby doesn’t recognize.
How do I fix it?
The first question to ask yourself is, did you define the method or variable in question? I can’t tell you how many times I’ve tried to call a variable that I forgot to define. Check your spelling. Sometimes the problem is as simple as a spelling error in the variable or method you’re trying to call. Or did you assign something to a variable called «user_input», but mistakenly call it «input» in your method? Have you actually built the method you’re trying to call? If that all checks out, then you need to think about scope (if you have no idea what I mean by scope, click here). Did you assign a local variable in one method and try to call it in another?
SyntaxError
32: syntax error, unexpected end-of-input, expecting keyword_end
What the what?
By far the most common error I encounter every day is the syntax error. You’ll see this bad boy pop up when there is something amiss with the structure of your code. For instance, if you forget an end somewhere.
How do I fix it?
Do what the error says. Fixing this one is as simple as adding an end where it says it needs one. Except when it’s not. Sometimes the error message will say you need a closing end but the source of your trouble is actually several lines above. Start at the top of your code and follow it down, making sure that everything is syntactically correct. Did you iterate over something (do) and forget to close it with an end? Are all your if, elsif, and else statements being used properly? One thing that will help you immensely is to learn to indent your code properly as you write it. Keep your code as organized and clean as you can. It will make it much easier to catch your syntax mistakes along the way.
NoMethodError
What the what?
Closely related to the NameError is the NoMethodError. This means that you are trying to call a method on an object that doesn’t know how to do what you’re asking it to do. If you try and do math with a number that’s a string and not an integer, for instance, or if you created a variable with a nil value, and then forgot to assign another value to it.
Imagine a scenario in which you want to manipulate a range of numbers. You’re not sure how to begin, so you start with something like this:
def split_numbers
1..10.split
end
If you try running this code to see what it returns, you would see:
errors.rb:2:in `split_numbers': undefined method `split' for 10:Integer (NoMethodError)
How do I fix it?
Google around and make sure you’re using the right method for your object. In the example above, calling .split won’t work because you can’t call it on an integer, even if you’re dealing with a range of integers. It’s a method that operates on strings. Take a close look at your code, as well. It might not be so much that you’re using the wrong method, but maybe you’re using it in the wrong way.
ArgumentError
What the what?
Say we have the following method:
def upcase_this_string(string)
puts string.upcase
end
If we call upcase_this_string("I love Ruby"), it will output «I LOVE RUBY». But if we call upcase_this_string("I love Ruby", "a lot"), we’ll see this:
1:in `upcase_this_string': wrong number of arguments (given 2, expected 1) (ArgumentError)
What this is telling you is that you gave two arguments in your method call, but your method was written to only take one argument.
How do I fix it?
There are a few scenarios that will cause Ruby to throw an ArgumentError, so make sure the number of arguments are correct, and that the datatype you are trying to use is valid.
TypeError
What the what?
This particular error had me confused for a long time, and I’m sure I’m not alone, so let’s dig in. Let’s say you’re doing some super simple arithmetic:
def add_one_plus_one
puts 1+1
end
Calling add_one_plus_one and running this file will output 2 to your terminal. but what if instead of puts 1+1, you had for some reason written puts "one"+1? You would see:
errors.rb:2:in `+': no implicit conversion of Integer into String (TypeError)
How do I fix it?
Basically, all Ruby is telling you here is that when you tried to call +1, it expected the value behind the + sign to be an integer as well. Instead, you tried to call +1 on a string. Ruby encountered an object that wasn’t the type of object it expected it to be. So make sure that for whatever operation you are trying to perform, you are using the proper type of object. For this example, it would have to be either 1+1 which would output 2, or "one"+"one", which would result in "oneone".
FUN-FACT
You’ve probably heard that Ruby is a pure object-oriented language, and that everything in Ruby is an object. Would it blow your mind if I pointed out that this holds true for your errors as well? Errors are objects, instances of the Exception class. If you don’t find this cool yet, just wait. Object-orientation is awesome. Suspend disbelief until you get there, and you’ll see what I mean.
RESOURCES
For more information on the Exception class, and Ruby errors, see the Ruby docs
If I’ve done my job, error messages now seem more understandable, less intimidating, and you now have some idea how to resolve them. If you found this post helpful, please share it with anybody else who might benefit from it. I am always eager to learn and improve, so I would love to hear what people think of this.
If you feel so inclined, follow me on Twitter. I always love to meet new people in the programming community.
Happy coding!
Built-in Exception Classes
NoMemoryError
Raised when memory allocation fails.
NoMemoryError Reference
ScriptError
ScriptError is the superclass for errors raised when a script can not be executed because of a LoadError, NotImplementedError or a SyntaxError. Note these type of ScriptErrors are not StandardError and will not be rescued unless it is specified explicitly (or its ancestor Exception).
ScriptError Reference
LoadError
Raised when a file required (a Ruby script, extension library, …) fails to load.
require 'this/file/does/not/exist'
raises the exception:
LoadError: no such file to load -- this/file/does/not/exist
LoadError Reference
NotImplementedError
Raised when a feature is not implemented on the current platform. For example, methods depending on the fsync or fork system calls may raise this exception if the underlying operating system or Ruby runtime does not support them.
Note that if fork raises a NotImplementedError, then respond_to?(:fork) returns false.
NotImplementedError Reference
SyntaxError
Raised when encountering Ruby code with an invalid syntax.
raises the exception:
SyntaxError: (eval):1: syntax error, unexpected '=', expecting $end
SyntaxError Reference
SecurityError
No longer used by internal code.
SecurityError Reference
SignalException
Raised when a signal is received.
begin
Process.kill('HUP',Process.pid)
sleep # wait for receiver to handle signal sent by Process.kill
rescue SignalException => e
puts "received Exception #{e}"
end
produces:
received Exception SIGHUP
SignalException Reference
Interrupt
Raised when the interrupt signal is received, typically because the user has pressed Control-C (on most posix platforms). As such, it is a subclass of SignalException.
begin
puts "Press ctrl-C when you get bored"
loop {}
rescue Interrupt => e
puts "Note: You will typically use Signal.trap instead."
end
produces:
Press ctrl-C when you get bored
then waits until it is interrupted with Control-C and then prints:
Note: You will typically use Signal.trap instead.
Interrupt Reference
StandardError
The most standard error types are subclasses of StandardError. A rescue clause without an explicit Exception class will rescue all StandardErrors (and only those).
def foo
raise "Oups"
end
foo rescue "Hello" #=> "Hello"
On the other hand:
require 'does/not/exist' rescue "Hi"
raises the exception:
LoadError: no such file to load -- does/not/exist
StandardError Reference
ArgumentError
Raised when the arguments are wrong and there isn’t a more specific Exception class.
Ex: passing the wrong number of arguments
raises the exception:
ArgumentError: wrong number of arguments (given 2, expected 1)
Ex: passing an argument that is not acceptable:
raises the exception:
ArgumentError: negative array size
ArgumentError Reference
UncaughtThrowError
Raised when throw is called with a tag which does not have corresponding catch block.
raises the exception:
UncaughtThrowError: uncaught throw "foo"
UncaughtThrowError Reference
EncodingError
EncodingError is the base class for encoding errors.
EncodingError Reference
FiberError
Raised when an invalid operation is attempted on a Fiber, in particular when attempting to call/resume a dead fiber, attempting to yield from the root fiber, or calling a fiber across threads.
fiber = Fiber.new{}
fiber.resume #=> nil
fiber.resume #=> FiberError: dead fiber called
FiberError Reference
IOError
Raised when an IO operation fails.
File.open("/etc/hosts") {|f| f << "example"}
#=> IOError: not opened for writing
File.open("/etc/hosts") {|f| f.close; f.read }
#=> IOError: closed stream
Note that some IO failures raise `SystemCallError’s and these are not subclasses of IOError:
File.open("does/not/exist")
#=> Errno::ENOENT: No such file or directory - does/not/exist
IOError Reference
EOFError
Raised by some IO operations when reaching the end of file. Many IO methods exist in two forms,
one that returns nil when the end of file is reached, the other raises EOFError.
EOFError is a subclass of IOError.
file = File.open("/etc/hosts")
file.read
file.gets #=> nil
file.readline #=> EOFError: end of file reached
EOFError Reference
IndexError
Raised when the given index is invalid.
a = [:foo, :bar]
a.fetch(0) #=> :foo
a[4] #=> nil
a.fetch(4) #=> IndexError: index 4 outside of array bounds: -2...2
IndexError Reference
KeyError
Raised when the specified key is not found. It is a subclass of IndexError.
h = {"foo" => :bar}
h.fetch("foo") #=> :bar
h.fetch("baz") #=> KeyError: key not found: "baz"
KeyError Reference
StopIteration
Raised to stop the iteration, in particular by Enumerator#next. It is rescued by Kernel#loop.
loop do
puts "Hello"
raise StopIteration
puts "World"
end
puts "Done!"
produces:
StopIteration Reference
ClosedQueueError
The exception class which will be raised when pushing into a closed Queue. See Queue#close and SizedQueue#close.
ClosedQueueError Reference
LocalJumpError
Raised when Ruby can’t yield as requested.
A typical scenario is attempting to yield when no block is given:
def call_block
yield 42
end
call_block
raises the exception:
LocalJumpError: no block given (yield)
A more subtle example:
def get_me_a_return
Proc.new { return 42 }
end
get_me_a_return.call
raises the exception:
LocalJumpError: unexpected return
LocalJumpError Reference
NameError
Raised when a given name is invalid or undefined.
raises the exception:
NameError: undefined local variable or method `foo` for main:Object
Since constant names must start with a capital:
Integer.const_set :answer, 42
raises the exception:
NameError: wrong constant name answer
NameError Reference
NoMethodError
Raised when a method is called on a receiver which doesn’t have it defined and also fails to respond with method_missing.
raises the exception:
NoMethodError: undefined method `to_ary` for "hello":String
NoMethodError Reference
RangeError
Raised when a given numerical value is out of range.
raises the exception:
RangeError: bignum too big to convert into `long`
RangeError Reference
FloatDomainError
Raised when attempting to convert special float values (in particular Infinity or NaN) to numerical classes which don’t support them.
Float::INFINITY.to_r #=> FloatDomainError: Infinity
FloatDomainError Reference
RegexpError
Raised when given an invalid regexp expression.
raises the exception:
RegexpError: target of repeat operator is not specified: /?/
RegexpError Reference
RuntimeError
A generic error class raised when an invalid operation is attempted. Kernel#raise will raise a RuntimeError if no Exception class is specified.
raises the exception:
RuntimeError Reference
FrozenError
Raised when there is an attempt to modify a frozen object.
raises the exception:
FrozenError: can't modify frozen Array
FrozenError Reference
SystemCallError
SystemCallError is the base class for all low-level platform-dependent errors.
The errors available on the current platform are subclasses of SystemCallError and are defined in the Errno module.
File.open("does/not/exist")
raises the exception:
Errno::ENOENT: No such file or directory - does/not/exist
SystemCallError Reference
Errno
Ruby exception objects are subclasses of Exception. However, operating systems typically report errors using plain integers. Module Errno is created dynamically to map these operating system errors to Ruby classes, with each error number generating its own subclass of SystemCallError. As the subclass is created in module Errno, its name will start Errno::.
The names of the Errno:: classes depend on the environment in which Ruby runs. On a typical Unix or Windows platform, there are Errno classes such as Errno::EACCES, Errno::EAGAIN, Errno::EINTR, and so on.
The integer operating system error number corresponding to a particular error is available as the class constant Errno::error::Errno.
Errno::EACCES::Errno #=> 13
Errno::EAGAIN::Errno #=> 11
Errno::EINTR::Errno #=> 4
The full list of operating system errors on your particular platform are available as the constants of Errno.
Errno.constants #=> :E2BIG, :EACCES, :EADDRINUSE, :EADDRNOTAVAIL, ...
Errno Reference
ThreadError
Raised when an invalid operation is attempted on a thread.
For example, when no other thread has been started:
This will raises the following exception:
ThreadError: stopping only thread
note: use sleep to stop forever
ThreadError Reference
TypeError
Raised when encountering an object that is not of the expected type.
raises the exception:
TypeError: no implicit conversion of String into Integer
TypeError Reference
ZeroDivisionError
Raised when attempting to divide an integer by 0.
42 / 0 #=> ZeroDivisionError: divided by 0
Note that only division by an exact 0 will raise the exception:
42 / 0.0 #=> Float::INFINITY
42 / -0.0 #=> -Float::INFINITY
0 / 0.0 #=> NaN
ZeroDivisionError Reference
SystemExit
Raised by exit to initiate the termination of the script.
SystemExit Reference
SystemStackError
Raised in case of a stack overflow.
def me_myself_and_i
me_myself_and_i
end
me_myself_and_i
raises the exception:
SystemStackError: stack level too deep
SystemStackError Reference
fatal
fatal is an Exception that is raised when Ruby has encountered a fatal error and must exit.
fatal Reference