Debugging Java with Eclipse

This lab will walk you through the basic steps of using the Eclipse debugger. For this lab, we will use the program you created in this earlier lab.

An automated debugger should allow us to set breakpoints, run the program until hitting a breakpoint or a run-time error, examine the call stack and data whenever the program is stopped, and to step through the code in steps of varying sizes. You’ve probably worked with such tools before, so we’re only going to do a quick tour here.

1. Start Eclipse and return to the workspace that you used in the earlier lab. Open your Pie project (if necessary) by right-clicking ion it and selecting “Open”.

2. Open Pie.java in the editor and set a breakpoint in the setSliceAngle function by double-clicking in the margin to the left of the assignment statement. A small blue circle should appear to indicate that a breakpoint has been set.

3. In the Package browser, right-click on PieSlicer.java and select “Debug as…Java Application”. After the first time you have run a program, you can repeat this via the bug button in the toolbar. You may be asked whether you want to open the debugging perspective. Answer yes.

   The program will execute and will stop at the first call to setSliceAngle.

4. In the upper left, you can see the stack of active calls (activations) that led you to this point. setSliceAngle was apparently called from within the Pie constructor, which was called from the PieView constructor, which was called … and so on down to PieSlicer.main(). Clicking any of those lines shows you the point of the call.

5. In the upper right, you can see a list of the parameters and local variables in the function call currently being displayed. Click on the various function calls on the left and observe how the list of parameters and variables changes.

6. Ranged above the list of function activations, you can see the controls for the debugger. Hover your mouse over these to see what they do.

   Click the Resume button to move forward to the next hit on this breakpoint. The window displaying our application will probably appear. In fact, if it appears far enough away from your mouse, the program won’t actually pause because the setSliceAngle function has not been called again. Move your mouse inside the pie so that the program pauses.

7. This time, setSliceAngle will be called from PieView.TrackMouse. Click on that activation and look at the data. x and y and the various numeric variables that follow it are easy enough to understand. Clicking on one of those variables causes its value to appear in the box at the bottom of the data area. For the numeric variables, this does not tell us anything new.

   Click on the activation of setSliceAngle. You can see the value of the numeric input parameter easily. The “this” above that refers to the particular pie that setSliceAngle was called upon. Click on the triangle to the left of “this” to expand it. You can see each of the data members. Many of these can be expanded to show their internal data members. In theory, we could examine the value of anything by expanding it enough times. That can be rather tedious with complicated types, however.

8. As a quicker way of viewing the value, click on “this” to select it. In the box below the listing, you will see something like “Pie [baseColor=…]”, which actually gives the value of each data member of our Pie class.

   Now, you might think that the debugger is generating that listing for us. But, in the editor pane, look at the toString function that we created earlier. You can see the opening string “Pie [baseColor=” followed by a lot of code to build a string out of the entire list of Pie data members.

   In fact, the debugger displays variables for us by invoking the variables’ toString() function.

   Try replacing the body of the Pie toString function by

   return "Yum!";
   

   Save your change and click on “this” again. Notice that the displayed value does indeed change to this less-than-informative string.

   Try removing the toString function entirely from the Pie class. You’ll probably be asked to restart the running program. Go ahead and let the debugger restart it. When the new execution halts, click on “this” again. You’re now looking at the default output that the debugger uses for classes that do not provide a toString() function. Not very useful, is it? You can see why I say that almost every class should provide that function, and why it’s so convenient that Eclipse can generate a useful version for us.

9. You can continue playing with this code a bit. Try out the various stepping controls for moving incrementally through the code. They should be, by and large, familiar to you from other debuggers that you have worked with.

10. When you are done, exit Eclipse.