Outline of Class 10: Debugging and Java Wrapup

Miscellaneous

• Oh boy, assignment four is ready. It's time for you to evaluate each other.
• Since you're commenting on each other's work, I may not assign grades for assignment three. The main purpose of homework is to help you learn, anyway.
• Okay, it's now been three weeks. Any new comments on these outlines (other than notes that I can't spell)?
• Sign up for the barbeque!
• This Sunday night's dinner is now filled. Any more takers for next week? You get to meet my beloved wife, as well as my crazy child.
• Today, Ms. Doll and Mr. Wislocki will be presenting an overview of some fascinating topic.
• To get the count of lines in a file, use
  wc -l file
• To get the differences between two files (e.g., if you wanted to count number of modified lines), use
  diff oldfile newfile
• Read about rcs for next Monday.
• I've done my best to turn back all of your grades for HW2.
• Today is the debut of my new, somewhat randomized, program for choosing who gets to answer questions in class.

Debugging

• Many of you have come to me with one or more bugs in your programs, and we've looked at various ways of identifying those problems. Today, we'll look at some general debugging strategies.

Program design and coding style

• The best way to catch bugs is to not insert them in the first place, or to document your code sufficiently well that they become "obvious".
• Use preconditions and postconditions whenever possible. You may even find it useful to explicitly test both pre and post-conditions in your code.
  • You can find documentation for a library for pre- and post- conditions at http://www.math.grin.edu/~rebelsky/Courses/152/97F/BaileyDocs/structure.Assert.html.
  • You should already have that library in your CLASSPATH. If not, add u2/rebelsky/Courses/152/structure.zip to your CLASSPATH.
  • You can also add assertions within your code.
• Break your programs into appropriately small pieces and test each piece separately.
  • Good object design will suggest a number of classes.
  • Whenever possible, test each class in isolation.
• Design before coding. That is, specify what your algorithms are supposed to do and sketch how they're supposed to do those tasks before you sit down and figure out how to implement each step in your language of choice.
• I've even caught a few bugs by reading the javadoc documentation for a program. Sometimes, the methods you think you've defined you haven't.

Debuggers

• Even the best coders sometimes make mistakes, and can only figure out where a bug occurs by tracing their code.
• Debuggers are tools for tracing code. They let you single-step through your code, printing variables as you go. They also let you set breakpoints so that your steps can be large enough.
• Most people find visual debuggers particularly useful. These debuggers use a windowing system and GUI to provide you with all the information at once. Unfortunately, our visual Java debugger runs too slowly to be useful.
• An alternate strategy is to use a line-oriented debugger. jdb is the line-oriented debugger for Java, and doesn't seem to be all that easy to use.

Extra output

• When debuggers aren't available, or when they are inconvenient to use, a common strategy for finding bugs is to add output statements to your program that indicate which lines your program has reached (or has not reached) and the values of key variables at those points.
• Rather than simply inserting and removing these commands, it may be best to provide a mechanism for turning them on and off.
• The simplest such strategy is to associate a private boolean constant with each class, and use that constant to determine whether or not to print debugging messages.

  // Are we debugging our bug-filled monstrosity?
  private static final boolean DEBUGGING = true;
  ...
  if (DEBUGGING) {
    System.out.println("In this method the value of variable is value.");
  }
  

• An extension of this strategy is to provide a separate debug() method (or Debug class).
  • Consider using one Debug object per object you're debugging.
  • You can initialize the Debug object with a name for your current class so that output makes more sense.
  • You can develop different types of debuggers with the same general interface.
• I'll try to provide one for you sometime next week.

Java Wrapup

• After today (or perhaps next class), Java will no longer be a primary topic of discussion. At this point, I think you have enough of the language "under your belt" to permit you to read documentation and develop programs.
• What haven't we covered? A number of things, which include
  • The full AWT
  • Threads and multitasking
  • Networks
  • Java Beans
  • Much more
• Depending on what you choose as a project, you may have to do more reading on these topics.