Monday, January 29, 2007

Scanner

I was recently helping somebody who is taking "beginning Java" kind of class. It's interesting to see Java as a first language, especially Java 5+. Java is unusual as a first language because of its object orientation. I think Pascal, Basic, or C are probably better choices. They're much less useful choices in the long run, I suppose. Java 5 as a first language is an even stranger choice, because of all that syntactic sugar...

For example, the Java student in question needed to write a program that accepted user input. Enter Java 5's java.util.Scanner. This thing is like C's scanf, but an OOP version of scanf. It's not quite as easy as C++'s cin, but you just can't do cin in Java because you can't overload the operator like you can in C++. I guess reading user input is one that is dramatically more difficult in Java than C++, well at least before Scanner.

One weird thing with Scanner is that it breaks on all whitespace by default. So don't use it's next() method to read strings that might have spaces in them. Instead use nextLine(). It accepts a regular expression for it's delimiter. That's pretty novel. Of course it means that if you want to use something other than the default delimiter, you'll need to understand Java's overly verbose version of regular expressions.

So I'd still prefer Pascal or C as a first language for a new programming, but Java has become more accommodating at least for beginners. The "old way" of reading lines of input was always something like:

String str = null;
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
try {
str = br.readLine();
} catch (IOException e) {
e.printStackTrace();
System.exit(1);
}

Talk about ugly! Now with Scanner:

String str = null;
Scanner scanner = new Scanner(System.in);
str = scanner.nextLine();

Or even:

String str = new Scanner(System.in).nextLine();

One of the key things to notice here is that you don't have to catch an IOException. Java has finally started being smarter with exceptions. Scanner's exceptions are not checked, so you don't have to catch them. There's no point in catching exceptions that you can't do anything about. If your program is unable to get input from the command line, it's not like you're going to be able to recover.

No comments: