Breakpoints and single-stepping

Create a project in Eclipse with the file:
Donuts.java

This is a short program that calculates the total cost for an order of donuts and coffees. See the javadoc for an explanation. The main method calls the private methoddonutHelper to do the actual calculation. There are couple of bugs. The errors may or may not be obvious to you, but either way, let us illustrate how a debugger might be used to find them quickly.

First, run the program and see that the outputs are incorrect. The main method attempts to find the cost of 52 donuts and 10 coffees. 52 donuts is four dozen plus four singles. That should be 35.00 for the donuts (4 * 8.00 = 32.00 for the four dozens, plus 4 * .75 = 3.00 for the singles), and we should get 8 free coffees, so the two additional coffees are 3.00, for a grand total of 38.00.

Setting a breakpoint

  1. Find the first line of the method donutHelper() and double-click in the left margin. You should see a small blue circle appear to the left of the line.
  2. Now, start the program again, but start it in "Debug mode". That just means that when you right-click on the project, choose "Debug As... Java Application" instead of "Run As...". (Alternatively, instead of using the "Play" button from the toolbar to run it, use the button with the little beetle-like icon.)
  3. A dialog comes up asking you whether you want to switch to "Debug perspective". Click Yes.
  4. You'll see an editor window with your code, along with some other unfamiliar panes.

    • The pane at the top left, labeled "Debug" is the call stack. At the top of the stack you can see donutHelper, the method currently being executed, and just below that you see main, the method that called it.
    • The pane at the top right has two tabs, labeled "Variables" and "Breakpoints". The Variables tab lists all the local variables that are currently in scope. You see two variables, namely the parameters donuts and coffees. There are other local variables defined later in this method, but at this point in the code, they haven't been defined yet.

Single-stepping with Step Over

  1. At the top of the Debug pane you'll see some controls with funny-looking arrows. If you hover your mouse over them, you'll see that the buttons are called "Step Into", "Step Over", and "Step Return" and that they are also available using the F5, F6, and F7 keys, respectively.
  2. Press the Step Over button (or the F6 key) once. This causes the current line of code to be executed. Notice in the Variables pane, the variable dozens is now defined. The green highlight in the editor pane is normally the line of code that is about to be executed.
  3. Use Step Over or F6 to step through the next line. Notice that now singles is defined too. At this point you can identify the first error in the program. Look at the values of the two incoming parameters, donuts and coffees. Weren't we trying to test this for 52 donuts and 10 coffees? We're calling it with the arguments mixed up. No wonder it's giving us incorrect values!
  4. Continue to step through the remaining lines of the method. When it reaches the end, you'll be back in the main method. Notice that the method donutHelper is no longer on the call stack.
  5. Press the square red button to terminate the program. Let's fix the error we found: in the main method, switch the order of the arguments to donutHelper. Note you can stay in the Debug perspective to edit your code and start it again. Remember to start it in Debug mode.

Managing breakpoints

  1. After fixing the code, let's set a breakpoint in main this time. Double-click in the left margin by the first line of main. Now, let's also disable the breakpoint we set before. Click on the Breakpoints tab, next to Variables. You'll probably see two breakpoints listed. Un-check the breakpoint in donutHelper to disable it - the debugger remembers where the breakpoint is, but won't stop execution there.
    • Eclipse will list all the breakpoints you've set in all your projects, not just the one that's open. To clean things up, you can remove a breakpoint by right-clicking on it and choosing Remove.
    • If you want to see the code where the breakpoint is set, just double-click on the listed breakpoint. (Use the back-arrow in the main toolbar to return.)
  2. After you've examined the breakpoints, click on the Variables tab again to make sure it's visible.

Step Into

  1. Now, run the program again in debug mode. It should stop on the first line of main. Press Step Over or F6 now and see what happens. Notice it executes the current line of code completely, including the method call.
  2. Step through the next line, which includes the call to System.out.println. You should see the correct output this time.
  3. For the next line, that is, the second call to donutHelper, let us try something different. In this case, we want to step into the method call so we can see what it's doing. Use the Step Into button or F5.
  4. Step through the first few lines. (When you see the coffees variable updated to a negative value, you should have a clue about what's going wrong. Note that variables that have changed are highlighted in yellow.)

Step Return

  1. Now, suppose we are done examining a method and want to just return to the point where it was called. That's what Step Return is for. Click the Step Return button or F7 and you'll be back on the line containing the call to donutHelper.
  2. Press Step Over or F6 to finish executing the current line. The green highlight will be on the println statement.
  3. Now we're going to do something odd that frequently happens by accident. Press Step Into again. Depending on exactly how your JDK is set up, you will either see a message saying "the source code is not available", or you might see the actual source code from some class in the Java libraries. Either way, we don't want to debug the Java libraries! Use your Step Return button to get back to your own code.
  4. Before you leave this page, fix the bug in the donutHelper method, and make sure you get the right output.

Switching perspectives

For regular code editing, you probably don't want your workspace cluttered with the extra panes in the Debug perspective. You can easily switch between perspectives.