Debugger Lab |
CS 159 CS 159 Docs Labs Projects Labs Lab 01 - Eclipse Lab Lab 02 - Memory Lab Lab 03 - Two-Dimensional Arrays Lab Lab 04 - Debugger Lab Lab 05 - Class Design Lab Lab 06 - ArrayList Lab Lab 07 - File I/O Lab Lab 08 - Unit Testing Lab Lab 09 - Inheritance I/O Lab View page source Edit this page Create child page Create documentation issue Print entire section Counting Golf Balls Instructions Debugging Resources Eclipse Debug Settings Tips for Using the Debugger Effectively Tag Cloud .equals1 .jar1 .toString1 2D-array2 accessor1 activation record1 arguments1 array3 arraylist1 checkstyle2 class design1 CLI2 command line2 constructor1 coverage1 data modeling1 debugger1 docs1 document2 eclipse3 editor2 enum1 exceptions1 file2 format2 gradescope1 heap1 inheritance2 input1 install1 jacoco1 jdk1 junit4 lab1 load1 memory1 mutator1 OOP1 output1 overload1 override1 polymorphism1 project5 project11 project21 project31 project41 read1 save1 setup1 stack1 stub1 test2 tutor1 unit test2 unit testing1 validate1 visualizer1 write1 Categories Docs2 Lab10 Project5 Labs Lab 04 - Debugger Lab Debugger Lab Tags: debugger eclipse Categories: Lab 3 minute read Counting Golf Balls Here's a fun little puzzle: If we lined up passenger busses, nose to nose, from Harrisonburg to Washington D.C., then we filled up each bus with golf balls, how many golf balls would we need? The program below attempts to compute that quantity! Spoiler Alert! nearly 20 billion Instructions Open Eclipse and add the following files to a Java project: Bus.java Estimator.java 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. 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. Estimator.exp shows the expected output when your corrected program runs 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. 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 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. 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 → Preferences → Java → Debug → Step Filtering OSX: Eclipse → Preferences… → Java → Debug → 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. Last modified March 12, 2022: add submission penalty to autograders (39cb837) © 2022 The Docsy Authors All Rights Reserved Privacy Policy About Goldydocs
