In Lab 11, you wrote a program that generated an inventory report highlighting items that were in short supply. In the actionPerformed method of that program, you used a try...catch control structure in which the catch section caught a generic Exception. If any kind of exception occurred, your catch clause displayed the message returned by the exception's toString method. The problem with that approach is that we have no control over the message that will be generated when an exception occurs.
Let's consider an example. Suppose the user specifies the name of an input file that doesn't exist (say, "junk.txt"). When the application attempts to open the file, a FileNotFoundException will be generated. When that exception is caught by the catch clause in my version of the program, the following message is displayed:
java.io.FileNotFoundException: U:\Java Projects\Lab11\junk.txt (The system cannot find the file specified)
While this message may make perfect sense to a Java programmer, it may be a bit more than an ordinary user needs to see. In this lab, you will modify your program to catch two likely exceptions and generate custom messages for these exceptions.
We are interested in catching the likely exceptions and displaying custom messages. So the first thing we have to decide is which possible exceptions are likely to occur when our program is executed. It is important to remember that we are not going to totally ignore the unlikely exceptions because we will still retain our generic catch clause which will deal with them.
The only way to know what possible exceptions might be thrown is to note the constructors and methods invoked in the try clause and look each of them up in the Java documentation to see if they throw any exceptions. For example, the showOpenDialog of our FileChooser object will throw a HeadlessException if the current environment doesn't have a graphical display device. This is unlikely to occur since our whole program is graphical in nature and we wouldn't get this far into the program if there were no graphical display device. There is no reason to worry about catching a HeadlessException. (If, on the other hand, we were using a FileChooser in a console-based application, this might be a legitimate concern.)
The constructor for the Scanner object will return a FileNotFoundException if the specified file does not exist. This is a likely exception.
The hasNext method of the Scanner class will throw an IllegalStateException if the scanner is closed. In our context, this is unlikely. I suppose it could happen if you were reading a file from a thumb drive and pulled the thumb drive out of the computer while your application was right in the middle of reading the file. But even that is unlikely to happen.
The "next" method of the Scanner class will also throw an IllegalStateException if the Scanner is closed. In addition, it will throw a NoSuchElementException if there aren't any more tokens in the input stream. This is unlikely to happen if we have been careful to use hasNext to make sure there is another token in the input stream before invoking "next".
In addition to an IllegalStateException or a NoSuchElementException, methods like nextInt and nextDouble will throw an InputMismatchException if the next token is not a valid representation of the corresponding data type. This is likely to occur if the data file has some sort of error in it or has been corrupted.
My point is that the application programmer has to be aware of what exceptions might be thrown in the try clause and then decide which of those exceptions the application will deal with. In this assignment, your application should catch a FileNotFoundException, an InputMismatchException, and any other Exception in that order.
Your application is to check for a FileNotFoundException, an InputMismatchException, and any other Exception in that order.
If a FileNotFoundException occurs, your program should display the message, "The file filename could not be opened." where filename is replaced by the name of the file specified by the user of your application (i.e., the name of the file that cannot be opened):
If an InputMismatchException occurs, your program should display the message, "An input error occurred while reading filename." The InputMismatchException is part of the Java.util library.
For any other exceptions, just display the value of the toString method for the exception as you did in Lab 11.
Submit your Lab12.java application as an attachment to an email message whose subject is "Lab12".