ITEC 120 2008spring ibarland, jdymacek

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

lab09a
PairODice regained
debugging tips

Finishing an object within an object

We will finish lab08b—printing: Pair O' Dice (checking off step 10). Note that since we've now talked about public and private, you can

• Make all your fields private
• Make most methods public (particularly Die's toString and PairODice's toString -- Java treats toString specially, and it won't compile unless it's public).
• Decide which methods should be private. For example, class Die's setFace should probably be private, because it's not intended for other people to set the face themselves; users should only be able to roll the die (roll) and check what value is showing (getFace) and get a String representation of the face (toString).

If you finish that, you can read on for fun…

Bonus Topic: Better println debugging

We mentioned in the PairODice lab, that one possible use of System.out.println is to help debug: You might stick in statements which print out the current value of a variable, or which just let you know that a certain method is even being called (perhaps indirectly). For instance, you might put a System.out.println inside a setter method, to see if a variable is ever being changed.

The problem with this approach is that you later need to comment out all those printlns. And then a while later, you might want to put them back in.

A better solution: your own class MyDebug

Instead of calling System.out.println directly, make a MyDebug class:

class MyDebug {
  boolean on = false;  // Is debug-printing turned on?

  /** Turn debug-printing on or off.
   * @param turnOn Turn printing on?
   */
  void setPrinting( boolean turnOn ) {
    this.on = turnOn;
    }

  /** Print a message (if debugging is currently turned on).
   * @param msg The debug message to print.
   */
  public void dprint( String msg ) {
    if (this.getOn()) {
      System.out.println( msg );
      }
    }

  /* Getter for `on`. */
  private boolean getOn() { return this.on; }
  }

By making several MyDebug objects, you can even have separate debugging for different parts of your code. (Although you now don't have a single master switch for all debugging.) In practice, one MyDebug object per class is usually about right.

Your task (optional): Add this class MyDebug to your lab. In PairODice, add such an object as another field. Add calls to dprint, and run your test cases. Then, turn printing off and run it again.
(Some people like providing a myDebug constructor which takes in the initial on/off status, as well.)

Possible extensions: you can generalize on to an int debugPriority; every call to dprint might include a priority-level of that information, and if that statement's priority level doesn't exceed the current debugPriority then it gets printed:

d.dprint(3, "Btw, the current value of x is " + x );
//or:
d.dprint(1, "Uh-oh, we unexpectedly reached the end of an if-else; Panic!" );

Drawbacks: since the debug-priority is set per MyDebug object, if you have several classes (each including a their own MyDebug), you can't set the debug-priority just once for all classes. (Well actually, that's actually the behavior you want some of the time.) Also, making the MyDebug object an extra field in each of your other classes can get annoying.
We'll talk about “static” methods this week, which can be used to get around both of these drawbacks.

Other methods of debugging:

• use assert statements.

• Use BlueJ's built-in debugger: if you click on the line-number in a BlueJ file, it will put a little stop-sign (a “breakpoint”) by that line. Then you can run your program/tests as normal, but when BlueJ reaches a breakpoint, it pauses executing and puts up a debugger-window. The debugger-window: (a) shows you all the local variables and fields of the current method/object, and (b) lets you follow the next lines step-by-step.

• Good programming: Writing small methods and making test cases is the best way to isolate bugs easily (and avoid them altogether).

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

©2008, Ian Barland, Radford University Last modified 2008.Mar.18 (Tue)

Please mail any suggestions (incl. typos, broken links) to iba�rlandrad�ford.edu