Debugger Lab

Counting Golf Balls

Instructions

1. Open Eclipse and add the following files to a Java project:
   • Bus.java
   • Estimator.java
2. Type your name at the top of each file (i.e., where it says ADD YOUR NAME HERE). Write your first and last name, just like you would at the top of an English paper. Don’t use ALL CAPS; those were only for instructions.
3. Debug the code by setting breakpoints and examining variables. There are several mistakes; notice that some of them are hard to find simply by testing. There is nothing wrong with the overall algorithm, but you might need to add a line or two.
4. Estimator.exp shows the expected output when your corrected program runs
5. Submit Bus.java and Estimator.java to Gradescope when you are finished. Your code should have no errors (9/10 points). The last point is for writing your name—you’d be surprised how many students forget that.
6. If you finish the lab early, use the rest of the time to work on PA1 and ask questions. Tip: Use the Eclipse debugger to “proofread” your code before submitting to Gradescope. You might save yourself a lot of time.

Debugging Resources

1. Video: Norm Krumpe’s Debugger Tutorial (~15 min) covers basic vocabulary and explains how to track variables in different areas in the Eclipse screen, the difference between step-in and step-out, etc.

2. Guide to Quick Start Debugging is a written reference with screenshots that explains how to get started and can serve as reminders of how things work as you debug.

Eclipse Debug Settings

If you haven’t already, update your Eclipse settings to prevent stepping into imported libraries:

• Windows/Linux:
      Window $\to$ Preferences $\to$ Java $\to$ Debug $\to$ Step Filtering
• OSX:
      Eclipse $\to$ Preferences… $\to$ Java $\to$ Debug $\to$ Step Filtering
• Check “Use Step Filters”.
• Select all of the available filters.
• Click the “Add Filter…” button and add org.junit.*
• Click “Apply and Close”.

Tips for Using the Debugger Effectively

• Never click “Step” before thinking about what you expect to happen.

  The debugger won’t magically tell you when something has gone wrong in your code. It only allows you to observe what happens one step at a time. If you don’t have an expectation for what should happen, you will have no way of noticing when something goes wrong.

• Never “Step-Into” a method unless you have already determined that it contains a defect.

  There is no need to waste time stepping through the instructions of a method that is working correctly. When you reach a method call, the default should be to “Step Over”. If the outcome is unexpected, you’ve learned there is a problem: now you can restart debugging and “Step Into” the method to figure out what’s wrong.

• Be prepared to rewrite code to be debugger-friendly.

  Imagine we step over the following statement and something goes wrong:

  bookshelf.addBook(library.removeBook(catalog.lookup("Of Mice and Men")));

  Now we are in an awkward situation. We know there is a problem on this line, but we don’t have a good way of narrowing it down. The debugger will be more useful if we rewrite the code as follows:

  BookID miceID;
  Book miceBook;
  
  miceID = catalog.lookup("Of Mice and Men");
  miceBook = library.removeBook(miceID);
  bookshelf.addBook(miceBook);

  This is more verbose, but it allows us to narrow down the source of the problem by stepping over one method call at a time.