E-Bookshop-master / uploads / file / Think-Java-How-to-Think-Like-a-Computer-Scientist_(1)

Appendix B

Input and Output in Java

B.1 System objects

The System class provides methods and objects that get input from the keyboard, print text on the screen, and do le input and output (I/O).

System.out is the object that displays on the screen. When you invoke print and println, you invoke them on System.out.

You can use System.out to print System.out:

System.out.println(System.out);

The result is:

java.io.PrintStream@80cc0e5

When Java prints an object, it prints the type of the object, PrintStream, the package where the type is de ned, java.io, and a unique identi er for the object. On my machine the identi er is 80cc0e5, but if you run the same code, you probably get something di erent.

There is also an object named System.in that makes it possible to get input from the keyboard. Unfortunately, it does not make it easy to get input from the keyboard.

System.out.println(s);

}

}

}

This rst line imports java.io, the package that contains FileReader, BufferedReader and the rest of the elaborate class hierarchy Java uses to do common, simple things. The * means it imports all classes in the package.

Here's what the same program looks like in Python:

for word in open('words.txt'): print word

I'm not kidding. That's the whole program, and it does the same thing.

B.4 Catching exceptions

In the previous example, processFile can throw FileNotFoundException and IOException. And since main calls processFile, it has to declare the same exceptions. In a larger program, main might declare every exception there is.

The alternative is to catch the exception with a try statement. Here's an example:

public static void main(String[] args) {

try { processFile("words.txt");

} catch(Exception ex) {

System.out.println("That didn't work. Here's why:"); ex.printStackTrace();

}

}

The structure is similar to an if statement. If the rst \branch" runs without causing an Exception, the second branch is skipped.

If the rst branch causes an Exception, the ow of execution jumps to the second branch, which tries to deal with the exceptional condition (a polite way to say \error"). In this case it prints an error message and the stack trace.

You can download this code from http://thinkapjava.com/code/Words. java and the word list from http://thinkapjava.com/code/words.txt.

Now go do Exercises 8.9, 8.10 and 8.11.

Appendix C

Program development

C.1 Strategies

I present di erent program development strategies throughout the book, so I wanted to pull them together here.

The foundation of all strategies is incremental development, which goes like this:

1.Start with a working program that does something visible, like printing something.

2.Add a small number of lines of code at a time, and test the program after every change.

3.Repeat until the program does what it is supposed to do.

After every change, the program should produce some visible e ect that tests the new code. This approach to programming can save a lot of time.

Because you only add a few lines of code at a time, it is easy to nd syntax errors.

And because each version of the program produces a visible result, you are constantly testing your mental model of how the program works. If your

mental model is wrong, you are confronted with the con ict (and have a chance to correct it) before you write a lot of bad code.

The challenge of incremental development is that is it not easy to gure out a path from the starting place to a complete and correct program.

To help with that, there are several strategies to choose from:

Encapsulation and generalization: If you don't know yet how to divide the computation into methods, start writing code in main, then look for coherent chunks to encapsulate in a method, and generalize the appropriately.

Rapid prototyping: If you know what method to write, but not how to write it, start with a rough draft that handles the simplest case, then test it with other cases, extending and correcting as you go.

Bottom-up: Start by writing simple methods, then assemble them into a solution.

Top-down: Use pseudocode to design the structure of the computation and identify the methods you'll need. Then write the methods and replace the pseudocode with real code.

Along the way, you might need some sca olding; for example, each class should have a toString method that lets you print the state of an object in human-readable form. This method is useful for debugging, but usually not part of a nished program.

C.2 Failure modes

If you are spending a lot of time debugging, it is probably because are using an ine ective development strategy. Here are the failure modes I see most often (and occasionally fall into):

Non-incremental developement: If you write more than a few lines of code without compiling and testing, you are asking for trouble. One time when I asked a student how the homework was coming along, he said, \Great! I have it all written. Now I just have to debug it."

Attachment to bad code: If you write more than a few lines of code without compiling and testing, you may not be able to debug it. Ever. Sometimes the only strategy is (gasp!) to delete the bad code and start over (using an incremental strategy). But beginners are often emotionally attached to their code, even if it doesn't work. The only way out of this trap is to be ruthless.

Random-walk programming: I sometimes work with students who seem to be programming at random. They make a change, run the program, get an error, make a change, run the program, etc. The problem is that there is no apparent connection between the outcome of the program and the change.

If you get an error message, take the time to read it. More generally, take time to think.

Compiler submission: Error messages are useful, but they are not always right. For example, if the message says, \Semi-colon expected on line 13," that means there is a syntax error near line 13, but putting a semi-colon on line 13 is probably not the solution. Don't submit to the will of the compiler.

The next chapter makes more suggestions for e ective debugging.

Appendix D

Debugging

The best debugging strategy depends on what kind of error you have:

Syntax errors are produced by the compiler and indicate that there is something wrong with the syntax of the program. Example: omitting the semi-colon at the end of a statement.

Exceptions are produced if something goes wrong while the program is running. Example: an in nite recursion eventually causes a

StackOverflowException.

Logic errors cause the program to do the wrong thing. Example: an expression may not be evaluated in the order you expect, yielding an unexpected result.

The following sections are organized by error type, there are some techniques that are useful for more than one.

D.1 Syntax errors

The best kind of debugging is the kind you don't have to do because you avoid making errors in the rst place. In the previous section, I suggested a development strategies that minimizes errors and makes it easy to nd them when you do.