CSCI 120 Lab 4


Objectives

Watching Variables and Methods using the Debugger

  1. Create a bluej project for this lab, and name it "lab4." Download all files for this lab into the lab4 folder.
  2. Download the files Account.java and Transactions.java into your lab4 folder. Add them to the project as usual.
  3. Run Transactions to see what the output looks like. Of course when you do this, you are running the main() method of Transactions.
  4. Let's see it (and the methods of the Account class) in action. "Seeing a method in action" is somewhat difficult working at the command line. But in BlueJ, you can stop a running method in its tracks and observe the contents of the parameters, local variables, and instance variables involved. The first step in this process is to set a breakpoint. This is a statement in the program at which the system will always come to a halt to allow you to see the values of the variables. Setting a breakpoint in BlueJ is very easy. Note that the source window has a margin on the left. By placing the mouse in that margin and clicking, you can position a little "Stop sign" next to any statement you want (to get rid of the stop sign, click again). Try it. In particular, position one stop sign next to the statement,
    acct1 = new Account ("Ted Murphy", 72354, murphyBalance);
  5. Run Transactions again. When the program reaches the breakpoint, it stops and a debugger window appears. In addition, an arrow in the code shows you exactly where the program has stopped. Look carefully for the local variable names in the depbugger window and note their values. Take a couple of moments to just look and understand what is happening at this point in the program.
  6. Hit the Continue button in the debugger window. This causes the program to run full speed ahead until the end (if there were any other breakpoints, it would stop at each of them first).
  7. You can also step through the program one statement at a time by hitting the "Step" button. Try that. Run Transactions yet again, but this time after it stops at the breakpoint, hit the "Step" button (the second from the left). Pay careful attention to what happens to the variables. Also note that if you double-click on an object (in the "Local Variables" box), the actual state of the object will be displayed. As you proceed stepwise through the program, you can watch the state of any object you like change. For example, double click on "acct1" and watch how the instance variables change.
  8. Now let's observe how methods and parameters work. For this, instead of the "Step" button, use the "Step Into" button (the middle one). Start up Transactions again, and step into every method invocation (that is, use the "Step Into" button exclusively) -- including the constructors (which is where you placed the stop sign)! As you step through the program, make note of all of the following, and be sure you understand your answers:
  9. Finally, some exercises: Add accessor methods to Account for the account number, the name, and the interest rate. They should have the obvious names (e.g., getAccountNumber()) and simply return the indicated instance variable. Test these methods in BlueJ, by creating an Account object and invoking the methods. Also add three statements to Transactions to demonstrate each of the methods.

Watching Variables in Loops

  1. Start by downloading the file BalanceTrouble.java, and add it to your lab4 project.
  2. Try running it. Unless you enter some very carefully chosen numbers as input, you won't get any output, because (as promised in the program's documentation), there's a bug in the program. Specifically, we have an infinite loop.
  3. Stop the runaway program by selecting View/Show Debugger, and pressing the Terminate button.
  4. Let's use the debugger to watch what's happening more carefully. Set a breakpoint on the line of the program containing the branch,

    if (currentBalance < 0)

    Your program will automatically stop whenever it reaches a breakpoint. This particular breakpoint will help us track down why this loop is infinite.
  5. Now run the program as usual. Enter some reasonable numbers for input, e.g., $20 for current balance, $500 for the desired balance, $20 for weekly deposit, $30 for negative balance penalty. Now watch what happens....
  6. The program will stop, and BlueJ will display the line at which the program stopped (exactly where you placed the breakpoint). Open the window wide enough to see the local variables. Look at the variables carefully. What are the contents of the variables? Are they consistent with what you entered?
  7. Hit the Continue button, and look at the variables again. What (if anything) has happened to countWeeks? What (if anything) has happened to currentBalance? Hit the Continue button a few more times. What is happening to currentBalance? Can you see why the loop will go on forever?
  8. Stop the program by hitting the Terminate button.

Bug Fixing

Now we come to the real point of this lab.

You can observe variables until you're blue in the face, but eventually you're going to want to fix whatever bug you have found. (The "debugger" doesn't debug your program for you; it's just a tool to help you figure out where the bugs are.) In this case, the person (my apologies!) who wrote the program BalanceTrouble.java must have forgotten that one should add on the weekly deposit to the current balance every week. To fix this aspect of the bug, you only have to add an assignment statement in the body of the loop.
  1. Fix the bug as described above. If you're not sure where to put the assignment statement, the specification is this: Let the bank add on the weekly deposit before it decides whether to charge a penalty.
  2. Run it again, with the debugger enabled. Use the same input set you used before. Observe what is happening to currentBalance. Is it changing as it should?
  3. If so, you can remove the breakpoint and hit the Continue button. The program should then run to completion, correctly.
  4. There's still a problem, unfortunately. Try running the program with an initial balance of -50 (note the negative sign), a weekly balance of $20, and a weekly penalty of $30. Could it be we still have an infinite loop on our hands?
  5. Kill the running program, and set a breakpoint within the loop again, as you did before. Where, exactly? Your choice. One suggestion is to place it at the assignment statement you added to the body of the loop back in step 1.
  6. Run the program with the same data given in step 4. Observe what is happening to currentBalance. Do you see why, for this choice of input, the loop will never end?
  7. Now let's fix this remaining bug. Here's one way to think about it: Suppose your initial balance is -$50.00, your weekly deposit is $20 and the weekly penalty is $30. That means that you will have a net of $10 subtracted from your account whenever it is negative. In the first week, your deposit of $20 just brings you up to -$30, so the penalty brings you down to -$60. The following week, it brings you down to -$70, then -$80, etc. It seems that if your balance after the first week is negative, and if your weekly deposit is less than the penalty, then the loop will be infinite. Work this line of reasoning into a decision structure enclosing the entire loop in a block statement that executes the loop only when we know it won't go on forever. The form of your code would probably be something like this:
          if (condition says loop is infinite because of negative amount)
              //print statement to say desired amount is never reached
          else
             {
                //loop goes here
                //followed by all the statements that print the results
             }
    

When you are done, print out and hand in any modified code, and submit your lab4 project electronically.



Back to CS 120 Home Page