Debugging is the process of detecting and removing errors in programming. This blog post is a guide that will help you debug your Java code in Eclipse.
The Debug perspective is the screen that you’ll view when you’re debugging a program. This features:
- Variables – what the value of each variable in your program is
- Breakpoints – where you want your program to stop and show you variable values
- Outline – shows all of the methods in your program
This looks intimidating, but it’s not bad once you break it down.
Before you start debugging, you’ll first need to insert breakpoints. Adding a breakpoint will tell your program where to ‘pause’ while running the code, so you can stop and see what’s going on.
Generally, you’ll want to insert your breakpoint at or just before the line of code that you suspect is causing problems. You can add breakpoints by double clicking on the left hand margin of the code editor, or right clicking there and selecting ‘Toggle Breakpoint’
To start the debugger, click the Bug button next to Run button on the top navbar. Alternatively, go to the Run menu and click Debug.
Once the debugger starts, Eclipse will automatically switch to the debug perspective and run the program up to the line of code where you placed the breakpoint. (Note: If code prior to the breakpoint requires user input like a Scanner, that will need to be entered first before the debugger will hit your breakpoint).
Notice the debug perspective will display variables and their values that have been executed so far. The value stored to radius is 5, which was supplied by the user and the Scanner object. Also notice the value of area is 0.0. While area was declared in line 9, nothing has been stored to it yet. (And, the default value for the Double data type is 0.0). Watch the variable change as you step through the code.
Stepping Into vs. Stepping Over
Now that the debugger is paused at your breakpoint, you are in control of executing the rest of the program. There are two main controls used to do this: Step Into and Step Over. (Hover over the buttons to see their labels)
Step Over will run the current line of code and immediately move on to the next one. If there are methods in that line of code, they will be executed, but you will not be able to see what happens inside of the method. Notice below that after running the generateArea() method, the value of area has changed.
With Step Over, the program executes that line and moves onto the next
Step Into however will allow you to see what happens as a method is executed. After you hit Step Into, the debugger will take you to the method that is running, where you’ll be able to step over (or into!) each line. This time you’ll notice that the variables displayed in the top right, now show the variables specific to generateArea(). When the method is done, control will be passed back to the main method, and the area and radius will reappear in the Variables window. (Hopefully, with an updated value for area, since that is what’s returned by generateArea()).
With Step Into, the program goes directly into the method
If you’re confident your methods are working correctly, you can just Step Over it. However, if you think your method might be part of the problem, you might want to Step Into it and see what’s happening inside.
There are a couple other buttons here worth noting. The Play button will continue running the program until it hits another breakpoint. This can be especially useful if you have two breakpoints that are far apart in your code. Instead of stepping over each line, you can just hit Play to get to your next breakpoint. The Stop button is straightforward–it stops your program and ends the debugger. It’s good to get into the habit of stopping the debugger when you’re done, or things can get weird.
We’ve gone over the basics for the debugger. Now what? While debug mode is really helpful for seeing your program broken down step by step, it is not going to fix your bugs for you. Watch your suspect variables closely as you step through each line. Are the values being stored what you expected? Is the program skipping over lines that it shouldn’t be? Practice using the debugger incrementally as you write your code instead of waiting until end, and use it often!
Still having problems? Come see us in the Sandbox to get help!