Debugging and fixing errors

Debugging means finding what the errors in your program are, and fixing them. This is something that at times are very hard, but becomes a lot easier with experience. There are two reasons why your program may not work. One is called a syntax error. A syntax error means that you did not follow the syntax, or rules, of the Java language. You forgot the semicolon, you mention a word that does not exist (not a keyword, class, or a predefined variable), or you forgot to call a variable properly, etc. These are all errors that can be checked by the computer. When you compile, the compiler checks each line of code, did you follow the rules or not. If it sees that you did not follow the rules, then it will not finish compiling, and it prints out an error. The compiler is saying, "I can not compile this because you are not following the rules, and I can't automatically fix it for you, because I do not necessarily know what you really want". When you get a compiler error, it usually looks like this. Notice a few things. The first line tells you where the error is, what class the error is in, the line number of the error, and what the error is. In my example cannot resolve symbol, meaning that the I do not understand what the word means, it is not a keyword, a class, or a variable that is predefined. '(' expected meaning that I had just started a method, and after each method name comes an '(', and I don't have one. The next lines explain it more, by telling me which symbol is not resolved (in my error), exactly which class had the error (if one class called or is part of another class), and points with an arrow '^' to the exact problem. Notice a second thing. In my code I created two errors. I put a space in the word private (a keyword) and I erased the "()" that was supposed to go after the method. However, the compiler found seven errors, why is that? The reason is because the first error caused that the compiler doesn't understand the first line. In the first line I am creating a variable called noise, telling the compiler that this is a kind of AudioClip, and telling it that it is private (a keyword that means that not everyone can use it- don't worry about it now). Whenever the compiler sees the word noise, it knows that it is a kind of audioclip. Now that I "accidently" put a space in the word "private", the compiler doesn't know what that line means (the words pri and vate don't mean anything to the compiler). So the compiler doesn't assign the word noise to an audioclip, and it doesn't know what the word noise means either. When you compile, a lot of times the compiler gives you errors that shouldn't be there. You look at the error, and look, and it seems that that line of code is exactly the way that it should be. The reason is because just like in my case, the error happened many lines earlier. You should first fix the errors that you understand, and then go through the list, fixing each one that you see. You'll be surprised, sometimes you will fix a small error (like you forgot the close brace) and twenty errors will disappear. What if you can only see a few errors at a time? If you are using the "CMD" (you clicked start, then run and typed cmd) in Windows XP, then you can right click the blue bar on top of the window, and change the properties to have a larger window so you can see more errors. If you are using an older version of Windows, then some allow you to change the properties, and some don't. What you can do is use an editor, like textpad that when it compiles it puts all of the errors on one of its own pages with a scrollbar.

The second kind of error is a logic error. This means that the code compiles and you have not broken any Java language rules. However, there is an error when you run the program. These kinds of errors are a lot harder to fix, because you don't necessarily know what causes the error. There are two kinds of logic errors. One that when you run the program the program gets stuck and crashes. The other, is where the program doesn't crash, but gives you the wrong results. In the second case, the best thing to do is hide it, and hope that no one else discovers the mistake (just kidding). In the first case, the screen will tell you which line caused the crash. (In an applet, the program won't crash, but will continue running with messed up results). This can sometimes be tricky, because the line that caused the problem might be elsewhere, and it caused a different line to show up. Also when it shows you the error, it shows a list of the chain reaction. Start at the top, because usually that is what caused the error. For example, if you are working with graphics, and you click the OK button, and now your program runs some complicated logic and crashes, the error will give the chain reaction, all the way to the button being pressed.

If you are stuck with an error that you can't resolve, then there are a few options. The best one is to ask a friend. Sometimes something that is impossible to the programmer is obvious to an outsider. Another option is to use an IDE which will tell you what your error is, and might even be right. The most practical and used technique is one known as printlns. You place a bunch of printlns (System.out.println("what you want to be printed");) at various places in the program. You tell it to print out information that you think should be according to your understanding one way, and see if it actually prints it out the way that you think it should. For example, let's say that you have created a complex math program. However, you test it out, and the answer kept in the number variable of finalAnswer is wrong. So you go through your code, and you cant figure out what went wrong. So you write out a bunch of printlns, all with the variable finalAnswer. In line 10 you tell the program to print out finalAnswer, in line 20, etc., Lets say in your mind you worked out that in
line 10 -finalAnswer should equal 24,
line 20 -finalAnswer should equal 24,
line 30 -finalAnswer should equal 46,
line 40 -finalAnswer should equal 698,
line 50 -finalAnswer should equal 78.
However, because of the println's you notice that on
line 10 -finalAnswer is 24,
line 20 -finalAnswer is 24,
line 30 -finalAnswer is 55,
line 40 -finalAnswer is 454,
line 50 -finalAnswer is 26,
then you realize that the error is between line 20 and 30.

There are two main ways not to produce errors, and to promote that if an error is caused it is easy to fix. The first is to read the code. Read it in real English, and you will notice a lot of bugs. Meaning if you have a line of code that is written as if(sum < sale) sale++; read it out loud as "If the sum is less than the sale, then add one to the sale". When you read it out loud you might notice that you really need the sum to be greater than, something that you didn't notice when it was in code. The second way is to break up the problem into different working chunks, and compile and run them separately. Imagine if your program was 1000 lines of code, and you wrote it all at once, and compiled it. You might have 52 errors. 20 of them might be because of one stupid error on top, like you forgot a '{'. When you see that you have 52 errors you might give up and throw in the towel. However, if you write one chunk of code at 50 lines each, it will become much easier. Also, again for example, the first half of your code was meant to come up with a specific number, and the second half was meant to do some computation. You can put in middle of the code a number for the first half, run it, and when that works, work on the first half. That way, if there is an error, you will only have to work on one half of the code at a time.

As I wrote at the top, this is something that is harder in the beginning, but becomes much easier when you get used to it. Good Luck.