Assignment 5

Task

Practice reading and debugging strange code.

Textbook: 1.5 (errors)

Scenario

Although you are only a young, inexperienced programmer, you have just been hired by the large faceless software company Exitech to fill one of their many office cubicles. Along with the cubicle, you have also inherited the software projects of the employee you are replacing.

You learn more about your predecessor from the other employees around the water cooler: he was considered a good programmer, though sometimes a bit careless and over-confident. In particular, he often neglected to compile his programs at all until he had written the entire thing. Apparently, this same careless over-confidence lead to his demise: he went spelunking last weekend, forgot to pack enough batteries for his flashlight, and is believed to have been eaten by a grue.

Your new boss doesn't know much about what Sammy was working on, except that it involved "fluids" and that the client requesting the software is adamant about being able to enter decimal numbers. He transfers the .java file to you and says, "Get it working!"

However, because you are new and inexperienced, he is also going to micro-manage you by having you document (in detail!) each bug that you fix.

Steps

The code: LiquidMeasureConverter.java

First, look though the code and determine what the program is supposed to do. Rename the file (and class inside) to UsernameA05a.java. Add your name to the empty @author tag under Sammy's.

Now work on getting the program to compile and run correctly. Do not add or remove any lines of code. (As a check, the final } should still be on line 37 when you're done.)

For each bug that you fix, record the following details:

• The line number the error is on. (Please precede it with the word "LINE" when you do this.)
• Whether the error is a compile-time, run-time, or logical error.
• What the source of the problem is, in your own words
• What you did to fix the problem.

So here's what you might write for the first bug that shows up when you try to compile the program:

  LINE 30: COMPILE
  Problem: Missing a semi-colon at the end of the line
  Fix: Added semi-colon

Please sort/record your bugs in order of line number. Save these in a plain text file named UsernameA05b.java.

What to Submit

Part A05a: Upload your UsernameA05a.java file to Tamarin. (The program should now compile and run correctly.)

Part A05b: Upload your UsernameA05b.txt bug report file to Tamarin.

Grading [5 points]

1.0 - Compiles

Your uploaded program compiles successfully.

1.0 - Program runs

And prints correct output

3.0 - Bug report

All bugs are reported, including line number (preceded by the word LINE), type (compile, runtime, or logical), problem, and fix.

FAQs

When I open the copy of LiquidMeasureConverter.java that I downloaded, everything is on one (or only a few) long line(s), with little boxes where the line breaks should be. Is that right?

No, that's not right.

The Reason: Different operating systems use different characters to represent the end of a line in a text file. Unix--which is what the www2.hawaii.edu server is running--just uses a line-feed character (ASCII value: 0A in hex, 10 in decimal, often represented as a '\n'). Windows uses both a carriage return (ASCII value: 0D in hex, 13 in decimal, often represented as a '\r') and a line-feed. Pre-OS X Macs used only a carriage-return.

Because of this difference, text files generally need their line endings adjusted as they pass between computers running different operating systems. Usually the software that handles this transfer (web browsers, FTP software, etc) does this translation correctly, but not always.

If you're encounting this problem, it's because the translation didn't happen for some reason: the line endings are still only represented by a single line-feed character. When you open the file in a very simple Windows editor like Notepad, it doesn't treat those single characters as line-endings, since it's not both a carriage return + line-feed. It also represents those strange (to it, anyway) single line-feed characters as little boxes.

The Solution: So, the easiest way to fix this is just to open the file in WordPad, not Notepad. (WordPad is found the same place as Notepad: Start -> Programs -> Accessories.) WordPad is a bit more sophisticated than Notepad, and it can handle the foreign line-endings. The file should look correct in WordPad. Just click Save, and close WordPad. Now open the file again in Notepad the problem should have been fixed.

(You can just work in WordPad if you want to. There's just a danger of accidently saving in Rich Text Format (RTF), which includes formatting details and is not plain text. Just make sure you save any new document as a Text Document and you should be fine. Also, WordPad doesn't display line numbers--which you sort of need for this assignment.)

Okay, I got the file to compile. But when I run it, it prints this:

Please enter a number of liters to convert: Exception in thread "main"
java.util.InputMismatchException
	at java.util.Scanner.throwFor(Scanner.java:840)
	at java.util.Scanner.next(Scanner.java:1461)
	at java.util.Scanner.nextInt(Scanner.java:2091)
	at java.util.Scanner.nextInt(Scanner.java:2050)
	at ZtomaszeA05.main(ZtomaszeA05.java:16)

This is a tricky bug. From this output, we can see that the program made it past the print statement on line 15, and then crashed trying to read an number on line 16. (This doesn't mean that the real cause of the error is necessarily on line 16 though! This is just where the program crashed.) The error (or exception) reported is an InputMismatchException. What this means is that Java read in something, but then crashed trying to convert that thing into an number for us.

What's so strange about this bug is that this is our first read from the Scanner. So there can't be anything in the input buffer that was read in earlier from a stream. Yet the program still didn't wait for the user to enter anything. In short, the Scanner is reading data from somewhere, and crashing because that data is the wrong format (not a number).

It would help our debugging to see what data the Scanner is reading in and choking on when trying to convert it to a number. To find out more, temporarily add before line 16 (or replace it with) this line: System.out.println(keybd.nextLine()); This reads in a line from the Scanner and just prints its contents to the screen. This might help you figure out what data the Scanner is reading.

One more hint: This bug is not due to with how we're calling the next methods (including nextInt, nextDouble, or nextLine). Instead, it's a problem to do with where the Scanner seems to be getting the data it is reading in. Where and how to we specify where a Scanner should read from?