Understanding error messages
As a junior developer, error messages were an instant reminder of how new I was to programming. In the beginning, an error message was just a reminder that I was new, but after some experience working in the field I realize now that the error messages are helpful rather than hurtful. Instinctively when I would get an error message in my code I would think “I have no idea how that would be wrong.” When the reality is error messages can be extremely helpful at describing what exactly is wrong.
It is always frustrating to see that the work we have been creating isn’t functioning properly, but without this frustration we would never be able to learn from our mistakes. If an error message explicitly responded back with the answer there wouldn’t be a deeper level of understanding necessary to learn from your mistake as well as to not make that mistake again. Furthermore, not understanding error messages, or having a vague error message, doesn’t allow us to use our skills as developers.
To begin we must understand how to read an error message. Typically an error message will tell you three things. It will tell you “where” your code is wrong, “why” your code is wrong, and “what” about the code is incorrect. Although that is the general layout the specifics of each of those conditions can vary depending on the programing language you are speaking. Ruby for example, can give very clear explanations as to why the code we are writing is incorrect. Bellow is a line of code I wrote to get an error message to illustrate how we can learn from a mistake.
Inside my console I called on a class called Song and asked ruby to use the array method #save on the class.
After I tried to run my command the console spit out an error message letting me know that the code I was trying to run wasn’t going to work. So to address this I have to understand the error. My error message was telling me exactly how I was wrong I just have to understand how to read it.
The error that was spit back said NoMethodError: immediately Ruby is telling me what kind of an error it is. Then Ruby spits back where the error is undefined method 'save' for #<Class:0x000055943a344aa8> . Then the error message goes as far as to tell you why with the last line from /usr/share/rvm/gems/ruby-2.7.2/gems/activerecord-6.1.4/lib/active_record/dynamic_matchers.rb:22:in `method_missing. Ruby is now telling me “Okay user, the code you wrote isn’t going to work because I recognize a NoMethodError: here undefined method 'save' for #<Class:0x000055943a344aa8> because from /usr/share/rvm/gems/ruby-2.7.2/gems/activerecord-6.1.4/lib/active_record/dynamic_matchers.rb:22:in `method_missing.” Putting this all together you can see start to see how your error came to be. The error was that a method doesn’t exist in the manner that's been laid out for Ruby, because Ruby in this case is using active record for its methods, and the method I called didn't exist. Since our error message was so specific I can stop and think about how I came to this mistake, and if I still cant understand how I came to my mistake I can start to lookup information about my errors.
In the beginning an error may seem like a reminder that you may need to refine some of your understanding of your code, but as you keep programming you being to realize that these errors aren’t what's stopping you from achieving your goal with programing but rather these errors are telling you that the way you’re trying achieve your goal isn’t the correct way to achieve it. Through these mistakes we become evolve into better programmers and with that evolution we turn our reminder of a mistake into our code letting us know that we should go about our programing differently.