Lab 4: Exceptions

Purpose: In this lab, you will rewrite your simple calculators from assignment one to use an input class that may throw exceptions. In addition to giving you experience with exception handling in Java, this laboratory also introduces the command line.

Preliminaries

As you may have noted, the SimpleInput class had some deficiencies. In particular, it was not very good about checking for end of file and the various routines had to return strange values when an error occured.

Many of these problems were due to an attempt to "simplify" input and output and to hide some of the underlying error system. However, Java has a nice mechanism for handling errors, one that we should take advantage of. The class SimpleReader provides similar facilities to SimpleInput() except that it throws exceptions when errors occur.

We can take advantage of this to make our Calculator programs more robust. In particular, we can use exceptions to handle the potential problems that may occur. What are those problems? I'd prefer that you think about it yourself, but you can find my answers at the end of this lab.

Once you have listed these problems, consider whether they are problems that the input object should identify and relay to your calculator or whether they are problems your calculator should identify.

Finally, consider the appropriate way to handle each problem. You can find my suggestions at the end of the lab.

Refining Your Calculator

Your primary task for this lab is to restructure your calculator to handle exceptions. Recall that there are two ways to handle methods that can throw exceptions:

• You can put the method in a try ... catch clause.
• You can indicate that your method throws the exception (in effect, that it passes the error on to the next level).

We will use both techniques as we work on improving your calculator. You should work with a copy of your calculator (which you will presumably rename in all the appropriate places). You can also use mine as a starting point.

Replace Your Input

To begin the lab, replace all references to SimpleInput in your program with corresponding references to SimpleReader.

Try compiling your program. You will, most likely, receive an incredibly large number of error messages. See if you can determine what each message means. You can also find explanations of common error messages in the notes section of this lab.

One way that you'll be able to get rid of most of these error messages is to add throws Exception to your declaration of main, as in

public static void main(String[] args)
  throws Exception
{
   ...
} // main(String[])

Try making that change and recompiling your program. If you still have errors, look at the notes at the end of this lab. Once you get the program to compile, see what happens when you use the program incorrectly (words instead of numbers, end of file at inopportune moments, etc.) In many cases, your program will terminate with a simple explanation as to where it terminated (or, more precisely, which method threw the exception and the chain of function calls to that method).

Catching exceptions

Obviously, crashing is not the best way to handle errors. Take out the throws clause from main and work on handling the errors with try ... catch clauses. If you're not sure which exceptions to catch, Java will tell you when you try to compile. For each exception that you need to catch, decide what the appropriate resolution mechanism is.

Once you have gotten your program to compile, test it with the various errors you've developed.

It is likely that this will be the longest part of the lab.

Reading from a file

If you have time, extend your program to read its input (the expressions) from a file, rather than from standard input. How do you do this? You can use a different version of the SimpleReader constructor that takes a file name as a parameter. How do you get the file name? You can prompt for it. However, it's also possible to get it from the command line.

The command line

You may have observed that when you exit typical shell commands, you list both a program and "arguments" to that program (most typically, files it's supposed to work with). Java provides you with access to those arguments. If you type
% ji Class alpha beta ...
and your main is of the form
public static void main(String[] args)
then within your main you can refer to the initial arguments (alpha, in this case) as args[0]. You can refer to the next argument as args[1]. And so on and so forth.

You can determine the number of command-line arguments with args.length.

If you have time

If you still have time, you might want to consider where your program should throw exceptions (e.g., when the user enters an incorrect operation) and extend your program to throw and catch those exceptions.

Notes

Typical error messages

Method eof() not found in class rebelsky.io.SimpleReader.

SimpleReader does not provide an eof() method. Instead, you are supposed to catch the appropriate exception.

Exception java.io.IOException must be caught, or it must be declared in the throws clause of this method.

You need to handle every exception. However, repairing this error may lead to further errors.

Class IOException not found in type declaration.

You've tried to catch an IOException but you haven't told Java which library contains that exception. You should include
import java.io.IOException;
at the beginning of the program. Some other important exceptions are

• java.io.EOFException (end of file)
• java.io.FileNotFoundException (guess)
• java.lang.NumberFormatException (couldn't read a number)
• rebelsky.util.NumberRangeException (number was outside the range of acceptble values)

Variable name may not have been initialized.

Java makes sure that you've assigned some value to each variable before you use it. When an exception is thrown in the course of an assignment, no value is assigned. Java is letting you know this. What is the solution? Make sure to assign a value in the catch clause.

Statement not reached.

By analyzing your program, Java has decided that there is absolutely no way that it can every reach that statement. This, most likely, reflects a problem in your design or understanding. Consider how you think one might reach that statement.

Problems with our calculators

Here are some of the input-related problems that I decided might go wrong with our calculator.

• The user might end the file at inopportune times (e.g., when we're trying to read the second argument). [Input]
• The user might enter something other than a number when a number is needed. [Input]
• The user might enter a number that is too large or too small. [Input]
• The computation might result in a number that is too large or too small. [Calculation]
• The user might enter an incorrect operation. [Calculation]

Some solutions to these problems

What should we do when these problems occur?

The user ended the file at an inappropriate time.

Print a message and terminate the program.

The user entered something other than a number when a number was expected.

Print a message, skip the rest of the line, and continue. We can skip the rest of the line by calling in.readLine()

The user entered a number that was too large or too small.

Print an error message and go on.

The computation resulted in a number that was too large or too small.

Print an error message and go on.

The user entered an incorrect operation.

Print an error message and go on.