Thread: Debugging your program

Welcome to a programmer's nightmare: debugging 101. This article will hopefully help you get a handle on the basics of debugging a program. For the purposes of this article, I will focus in the Eclipse debugger, though any debugger worth bothering about will have many of the same features.

Types of bugs

There are 3 main types of bugs: syntax/compiler, run-time, and logic. They run in that order from easiest to hardest to fix.

Syntax/Compiler Errors

These type of errors are any that literally will cause the compiler to fail and not spit out anything useful that can be run. The Eclipse (actually the Java compiler, but Eclipse indirectly) is very good at telling you what kind of typo you made to cause the compiler to complain.

int a = 5

If you type this into Eclipse, it will come back and say to you:

Syntax error, insert ";" to complete variableDeclarationStatement

It's quite obvious we forgot to insert the semi-colon ending the statment here, so just pop it in and Eclipse will cause the red "x" to go away telling you there's a problem.

Because of the way Eclipse was written, it has a special "auto-fix" option. If you hover your mouse over the red "x" (or yellow warnings, though these technically don't have to be fixed) and press the auto-fix shortcut (the default is ctrl-1), it will give you a list of suggested fixes. However, the compiler is not omnipotent, so it doesn't know exactly which fix to implement, or even sometimes what fixes to offer to do. A prime example is with the above code. It tells us that we need a semi-colon to complete the statement, but the auto-fix option doesn't give any suggestion on how to fix this.

I won't go through the list of the probably thousands of different errors you could get here, but if you follow the above method and do a little bit of googling/asking here, you should be able to figure out the basic syntax to satisfy the Java compiler.

Run-Time errors

These are any errors that occur when the program is running. This means that technically your program is syntax-error free (Eclipse is funny because it'll let you run a program up to a syntax error, but this is not the general case).

int a = 5;
System.out.println("Enter an integer: " );
int b = new Scanner(System.in).nextInt();
int c = a/b;

Here's a prime example of a run-time error. On almost all runs (99.999% of the time), it will work. However, if you input 0, 5/0 is undefined and Java will complain and throw a RuntimeException.

The default action (if you have no exceptions being caught by your program) is to print out the stack trace. This is basically a list of methods that was called to get to the line that caused the problem. They look something like this:

Exception in thread "main" [color=red]java.lang.ArithmeticException[/color]: / by zero
	at [color=blue]Test.main(Test.java:12)[/color]

The red stuff is what kind of exception was thrown, and the blue stuff is the list of methods called to reach that point, along with the line number in the source it occurred on.

Run-time errors are slightly tricky to debug. They require specific conditions to be satisfied (like here, inputing 0). The best plan of action is this:

1. Put a break point at each of the line numbers in the stack trace.
2. Run the program in debug mode (In Eclipse, click the little button right next to the play button that looks like a bug)
3. Try running your program with the same inputs that caused it originally to crash (ex. input 0).
4. When Eclipse hits a breakpoint, use the "step-over" button to step through your code line by line.
5. Depending on the error, you can look at various variables and there values in the "variables" tab (by default, Eclipse's variables tab is on the top-right panel in the debug perspective)
6. At some point, something won't look right. Common things to look for are variables having a null value when they're being used, dividing by 0, and any specific specifications from any methods you are calling (these are very diverse and won't be covered here).
7. If you run to the point where you have the exception thrown and still don't know what is wrong, get someone else (hopefully with some experience in programming) to take a look. THIS IS NOT TO SAY YOU CAN'T PROGRAM! A fresh pair of eyes is the best way to find something you might have missed that is causing the problem (similar to getting someone else to proof-read your papers). Obviously the person you get look at your code must have programming experience or else it would be like getting someone who has no knowledge of Ancient Egypt to make sure your paper on the Pharaohs of Egypt is factually correct.

Logic Errors

The hardest kind of bug to fix. These are hard because the computer doesn't really tell you anything is wrong because it compiled successfully and will run. However, you won't be getting the outputs you want.

int a = 5;
System.out.println("a is 5");
a = 10;
System.out.println("a is 5");

Here is a greatly simplified example. Say you want to print out the initial value of the variable a, and then print out the modified value of a.

When you run, it will print out this:

a is 5
a is 5

Nothing didn't compile, and there were no exceptions thrown (note: a lot of run-time errors result from having a logic error, the difference is very iffy).

The solution to debugging this type of an error is similar to debugging a run-time error. The only difference is you're going to have to guess a place of where the error could be occurring, and then go quite a ways back to make sure you reach the place that the logic error is occurring (note: as your code gets more complicated, logic errors won't be confined to one location in your code. They can be as wide as an entire algorithm. These types of errors are almost impossible to spot without doing some hand work to validated that your logic is working correctly).

Conclusion

Sound like a big pain to debug? It is The standard development cycle is maybe 10%-20% coding, and then 80% debugging.

Moral of the story: Don't make any bugs. And if you do, make sure they are syntax errors.

Real moral of the story: Any bugs you accidentally (and inevitably) make will probably take you and others at least 3 times as long to find (some causes may never be found for the lifetime of the software), and then take very little time to fix (comparatively).