Regardless of who you are, a student, a professional, or an average Joe/Jane, you are probably familiar with or have ran into the 404 Page Not Found, while browsing the web. You also may have wondered what a 404 is, and why so many different websites provide you with this notification, when their website is down or when you type a domain name that doesn't exist. This warning is a commonly known server error that happens when a user attempts to open a dead or broken link. However, from a users standpoint, this kind of error is confusing and frustrating to experience. However, from a developers standpoint, this error is easily handled and fixed if you know how to approach the problem. That being said there are many different types of error or bugs that someone can have while creating code, and I am here to help you understand how to solve these issues a bit better. That being said, I am not a professional debugger of any sort, but I do have various experience in writing and debugging code, so if you are a professional code tester, or debugger this is definitely not the place for you.
The first rule that I always go by when running into an error is, "check the little things". Now this advice, while it may seem obvious, is honestly the most important rule, when trying to solve all of the pesky problems you hit when writing working code. Now this advice may seem dumb, and you might ask, how would you define "little things"? And I would tell you by asking you to ask yourself, "what small mistake could I have made to break my code". Now what does this mean? Simply, I'm telling you to look for syntax or spelling errors. I find that a large majority of errors are user error, and you might be thinking, "thanks a lot Mr.Genius" in a sarcastic manner, but this approach is extremely helpful. The more you write code and the more you look at code the more fuzzy it can become and the more easy it can become skewed or messed up. For example, look at the word recipe. Let's say we start typing the word recipe, because we want to make an app, or webpage that has a lot of recipes or uses the word recipe a lot. Over time and through long hours, the more you look at the word recipe, the more reciepe, starts to look weird. And when you start noticing that the word reciepe starts to look weird, the more you question whether or not its your eye and brain playing tricks on you or if you are making a mistake. Now for the sharp ones reading this blog, you have probably noticed that midway through I started typing recipe weird and syntactically I spelled reciepe with an extra e. Now this is only one example of how you can make a simple syntax error, and how you can break your code because of this small mistake. Now when you look at this example visually, it's easy to tell that it's a syntax error and that the mistake is a spelling error, but let's look at how this error would appear if it was in a program.
Look at this example. This is an extremely simple example, but lets read and analyze what we see in the error message above. As we can see in this code, if you know ruby or similar languages, we have a variable named recipe. This variable is assigned a value of "This is a recipe". Now line 3 says puts reciepe, which should tell the computer to read what value is assigned to reciepe and return that value, but as you can see we get an error instead that says "undefined local variable or method reciepe". This is because we spelled recipe wrong and are trying to puts a variable that isn't created. Pretty straightforward. Let's take a closer look at the error though. So the error here is extremely helpful. First its finding, or Traceback, where we hit our error and it tells you, test.rb:3:in. Now what does that mean? It shouldn't take a genius to add up that test.rb is the name of the file that we ran, and that the 3 following it refers to the line number where the error occurred, because its followed by the in right after and if we look at our actual code, that all matches up. Next we get the actual error where it tells you what went wrong that we went over above. So if you can read you can clearly see what the problem is. However, not all errors are this simple.
Look at this example, this is an example of another common error, known as a logic or logical error. This type of error, is harder to fix, because like you see above, there is no visible error. This logical error is also hard because it makes you question your own knowledge as a developer. But because of this it brings out good questions to ask yourself in order to solve these types of problems. Some of these questions are: what am I trying to get my code to do, what kind of output should my code return, and lastly the hardest question to answer, am I actually writing the correct logic in order for this code to work. These simple questions, are question you must ask yourself in order for you to fully understand where you must look when trying to fix your problem. In the example above, like the previous one, we want to print out the variable recipe that we created and show it back to the user in the console. The first step, in knowing that it is indeed a logical error is that there is no visible error being returned to us in the console. However, more complex logical errors can also display a visual error so do not confuse simple errors with logical errors only on the fact that a visual error appears or not. But back to the code, we see above, if you know ruby, you would know that implicitly when a variable is called the return value of all variables is nil or empty. So when we call only recipe, in order to get its value back to us, in the console it returns nothing or nil. And this is how a logical error can be solved. Now all of these examples so far are simple errors that do not need much time, while solving, but what happens when you move to more complex problems? Do you need to change how you approach debugging the problem? No, you should ask the same questions, but you also might need to ask the harder question more often. The harder question being, am I actually writing my logic correctly when trying to make my program run correctly? Now what do I mean by "writing your logic correctly"? What this question is asking is, am I writing the correct code, to run that task that I want to run? For example, if you know about the built in ruby methods .each and .map, you will know that they are both enumerables, or methods that will run in a loop and can be adjusted to run in various different ways. However, these 2 methods being very similar in use case, they have one very distinct difference, while otherwise being the exact same method. This difference is that the .map method will return a new changed array, while the .each will return the original array unchanged. This is where the question "am I writing my logic correctly" comes into play. In the example with .each and .map, if you had code that uses one of these methods and you ran them, both would run without giving you visual errors, while the only one would provide you with the expected response. Though that being said you could write code that does give you visual errors with .each and .map, but thats not super relevant to explain. Because we are not talking about what methods give you errors, but if the logic in your code will give you errors or not.
Now that you've isolated the problem to a logic error, what steps should you take to fix it? If you know what logic problem it is, that makes things easy, and you can go straight to the source and edit the code and rerun your tests. Otherwise, here are a few things to try. One method would be to use one of the built in debugger tools or a debugger gem to help visual the steps your code is taking in order to see what is happening every step if the way in your codes life cycle. Some debugger tools are pry or byebug. If you want more info on these things feel free to google them. With these tools, you can stop your codes runtime, and run tests inside the terminal in order to isolate the problems source. If this doesn't help, or if I look at my code and the logic seems to work as I think it should, I head to my one true savior, Go.....ogle. Yes, as annoying as this might be, Google knows all. All jokes aside though, googling documentation about how certain programming methods, or code works can be a helpful solution to your problems. There are millions and millions of programmers out there and there's even more references and code/programs you can use as references to verify if you are coding correctly. Since the coding world is so big, chances are that a problem you run into has been ran into by someone else before too. So using your googling skills you can solve the errors you run into. However, that being said there are some do's and don't when it comes to googling errors. One of the major don'ts is to not just copy the whole error you get and paste it into your browser. Sure this might work some of the time, if your error is small or common, but if not you wont get anywhere and you'll be stuck googling for eternity trying to fix your problem. Rather than googling the whole excerpt of the error, it is okay to take snippets, preferably from the beginning or the end and pasting that into google and then reading and comparing your errors to those of other previous programmers.
Like for this example, sure if you copied this whole error, and pasted it into google, you might get lucky and get a result. But it would be better practice and a better learning experience if you copied only the first part "Syntax Error: Unexpected token < in JSON at position 0". This way your searches might be a bit more broad, and you'll be able to get more results. This also helps you in the long run to start to memorize errors and familiarize yourself with them and once you fix your problem, if you see a similar error message you might be able to isolate the problem easier the second time around. Like the verbiage Syntax Error, or Unexpected token, are very common error message that refer to usage of syntax that is extra or missing, when you need or should use different syntax instead.
Now before this blog gets too long I'll leave you off with one final example of a logic error I ran into, and how I managed to solve it(Though I did end up needing some outside help).
Now in this example, I have an webapp, that allows users to create an address and attach it to the users information, after creation of an account. However, because of how I setup my user and address relationship, the user is unable to create an address at the same time as when they create a login account. So the solution I came up with was, that when a user's account is created, they can add an address after the fact. Now the problem, I was facing was that when a user tried to create an address and that address was being added to the database, I would try and update the user, so that they would know what address the user belonged to. This relationship in databases is known as foreign key relationships or parent-child relationships. As you can see in the images above, the addresses were being created and stored into the database, but for some reason I was unable to update the address_id(foreign key) in the users database, to match the newly created address. So in order to check this I used one of the debugger tools at my disposal, byebug, so I could see step by step what was happening and surely, my address would be saved into the database, but when I would try and update my user, the update would rollback, or fail, but the program would continue on and render the website without a visual error of a problem. Step by step, I checked every logical part of my code, until I was finally stumped, and was pushed by a professor, to google some documentation on how to update or change a singular column in a database table. Which lead to, a discovery of a logic mistake that for some reason, the update method built into a program I was using, did not like updating only a single column, but wanted to use update_attribute, to do this task instead. And thus like magic, my problem was solved, and you can see with the yellow text in the image above "UPDATE users" worked and my database was fixed. True, this fix was aided by a professors suggestion, but it could also have arrived if I had first taken the time to google updating a singular element in a database versus multiple. There seemed to be a small gap in my knowledge in this aspect of editing databases.
Thanks for reading the really long and hopefully helpful blog, I apologize for how poorly it is written and how seemingly obvious all my tips were, but hopefully you gained some knowledge about how to approach errors and bugs. On final note is that there are way more kinds of errors and bugs that can occur than I went over and there are lots of things I wanted to cover but couldn't but feel free to ask or leave a comment below and hopefully I can reach them or help with them if I see them. Have a great one!