Computer Science 120
Introduction to Programming
Spring 2011, Siena College
This "mini-lab" is intended to be completed during your lab meeting before you begin work on the programming project.
"Debugging" is the process of finding and correcting the "bugs" or mistakes in our programs. Our graphical approach has a nice advantage for debugging - we can often see on the screen when something isn't quite right. A graphical object isn't in the position we expect, or it is drawn in a different color. This can often direct us to the mistake in our code.
Console Output
But not everything in our programs deals with a graphical object. Even if we do have a graphical object, our bugs sometimes result in the object not being visible at all.
Today, we want to consider another tool we can use when debugging: printing out information.
Java provides a mechanism to have our programs provide "terminal" or "console" output. The same kind of textual information we have been putting into Text objects can be sent to the terminal using the System.out.println() method.
For example, if we put the line:
System.out.println("Executing here!");
in our program, and we see the message "Executing here!" displayed in the terminal output, we will know that that part of the program has been executed.
To try this out, download one of the class examples and add a printout to one of the methods. Run it and see that the output is produced.
Just like we can build up strings to be displayed in Text objects, we can build up strings to print out. This can be used to print values of variables or even of something like a Location.
To try this out, pick a class example and add the line:
System.out.println("Mouse is at " + point);
to one of the mouse handling events. When that event happens, you will see the message printed with the point printed in a readable format.
If you are unsure of what one of your programs is doing, System.out.println can be a valuable tool to help find the problem.
Also see Section 3.8.2 of BDM for more information about System.out.println.
The NullPointerException
A very common error when working with objects in Java is the NullPointerException. This occurs when you attempt to call a method on an object with a given name, but the name does not actually refer to an object (its value is null).
To see an example of this, download a class example or use a copy of one of your lab programs to introduce such an error. For example, if you were going to use the FallingBalls example, you could insert a line into the FallingBall constructor just before the ball is constructed:
ball.setHeight(100);
If you compile and run the program, you will not see the expected ball falling down the screen when you click the mouse. Instead, you will get a terminal window with a bunch of red text at the bottom. While this might look like an indecipherable mess, there is some valuable information there. You are looking at a stack trace produced by Java when it encountered an error. The first line it prints is the cause of the error, in this case, that it is a java.lang.NullPointerException. Then it tells you where in the code it was executing. Most of the information here is meaningless to us - it tells us which Java classes and methods were being executed, most of which we have nothing to do with. But the first few lines should look familiar: it should list one or more of the classes we developed, and methods within those classes.
The first line of the stack trace tells us exactly what Java was trying to do when it encountered the error:
at FallingBall.<init>(FallingBall.java:31)
This says the class FallingBall was active, and the <init> means we were in the constructor. Then it tells us the file, FallingBall.java, and the line number, 31, where the error occurred. Very useful information!
Sometimes that is all we need to know (as is true in this case), but other times, the next few lines might also be helpful. The second line:
at FallingBalls.onMouseClick(FallingBalls.java:19)
tells us that the FallingBall constructor was called from the onMouseClick method in class FallingBalls at line 19 of the file FallingBalls.java. That makes sense - the bad constructor call was made in response to a mouse click.
As a general rule, any time you see a bunch of red text showing up at the bottom of BlueJ's terminal window, it's worth investigating. In the case of an error like this one, your program will stop working altogether, so you have no choice but to investigate (and fix) the problem. In some other cases, Java may give us some helpful information (perhaps you tried to use a piece of data incorrectly) that will cause some problematic behavior, but the error is not severe enough that Java cannot continue.
Drawing Memory Diagrams
For your last in-lab task today, draw a memory diagram like the ones you've seen in class for the FallingBalls example after the following events have occurred:
Grading and Submission
The only item to submit for this week if your memory diagram. Please hand it in before leaving lab, for 5 lab points.