Reading Errors/Exceptions in Ruby
NOTE: It is highly recommended that any new Ruby users use the Pry gem for debugging their code. I’ve linked more resources for pry here. It is also important to note that this post is written for new developers, by a new developer.
If you’re new to programming, one of the most intimidating and daunting tasks can be reading the errors in your code. We’ve all been there. You think you’ve done everything right, you go to run your code to see the results and BAM. Lines and lines of what looks like gibberish spewing out of your terminal telling you of all the mistakes you made in your text-editor, along with all of the mistakes you’re currently making in your life outside of coding. I’m kidding about the latter of course, but the former listing of your mistakes within the text-editor can be anxiety-building for new developers.
I’m here to tell you that you should not only throw your fear of errors away, but also lean into the error messages and use them to your advantage.
Okay, okay, so that first part was very touching and all, but what do you mean “lean into errors”? Great question. Errors don’t just tell you that you screwed the pooch, they also tell you the specific reason that your code isn’t working and often even the exact location of where your program is breaking.
All languages have different error messages (some being harder to decipher than others), but for the sake of this post we’ll focus on Ruby error messages also referred to as “exceptions”. Why Ruby you ask? Because Ruby’s focus on human needs rather than that of machines makes it a powerful yet easy language to learn for those new to programming. In this same vein, the less complicated syntax and descriptive error-messaging also make it one of the best languages for using “exceptions” (or errors) to quickly identify the source of your problematic code.
Alright so what good is all of this broad information to you, a new developer? Let’s get through three of the more common exception-type errors you will likely run into as you code.
NameError
Let’s say I have an application with players as objects for a simulation soccer game and I can create them with a Player class. Now I want to create a new player for the game. I’m going to use Pry to make sure that my code is working but something is wrong. If I run the above code, this is what I get in response below:
What happened?? Let’s break it down. In my models/player.rb file it points to line 19. Looking at my code I can see this is where I was trying to create a new player. The error says “uninitialized constant Players.” Silly me. My class is called Player NOT Players. NameErrors are exceptions that are raised when an object is invalid or undefined. They can quickly alert you to spelling errors or errors in your ordering of code. I’ll change my code to Player and we should be good to go. Let’s see what happens:
ArgumentError
Not again! But remember how easy it was to find the last error? Let’s not fret, but instead dive into the errors to get the solution. In my file it points to line 8 within my initialize method. It says I have the wrong number of arguments, that I’ve only given 4, when I should have given 5. My initialize looks good, but if I scroll down to where I was creating a new player, I’m missing an argument! I forgot to put in a nationality. ArgumentErrors are exceptions raised when the argument amounts are wrong OR when the arguments passed are invalid. Let me make the change now to see what happens.
Success! We made it through to Pry, which means our code had no errors in it. Now as you can see by the image above, I’d like to find out the education of the new_player object I just created. Let’s see what happens when I run this test in Pry:
NoMethodError
Oh no! What did I do now? If I look at this error within Pry, it says that there is an undefined method called ‘education’ for my new_player object. What does that mean? A NoMethodError is an exception that is raised when a method is called on a receiver (in this case my new_player object) which does not have it defined. If you scroll up to my original code, you’ll see that education is not a method I’ve created nor is it an argument I’ve passed in creating my objects. It doesn’t exist and won’t work unless I crate an argument or method called education. Instead I’ll try the method .team to see if that works, since that is an argument I passed.
Success! This worked because .team was a method I had defined already, both as an argument for my new_player object and also with the macro attr_accessor, which allows me to both read and change the team variable for each instance of the Player class that I create. NoMethodErrors are useful for discovering simple errors like this, but can also be useful for determining whether or not object associations are working when you have multiple classes interacting with one another. If you get this error when trying to connect multiple classes, chances are that your associations have some errors.
This is just the tip of the iceberg when it comes to utilizing error messages in Ruby to determine why/where exceptions are being raised, and how to correct your code so things run swimmingly. While these examples above are quite simple, the same principles of reading error messages can be used for much more complex errors and problems as well. The bottom line is that you should use error messages to help you solve problems and in many instances they will be your best source for what is going wrong in your code.
As a developer you will continue to make errors and break code no matter how experienced you become. Getting used to reading error messages early and often will create good future habits and will make your coding journey less frustrating overall.
Umm my name is Eli not Brett…but thanks for reading!
