Overview

The purpose of this lab is to work on your Java Exception skills. You'll start with a program that works OK, but only if the input is entered perfectly. The program processes commands. The commands are:

Your job in Part 1 will be to add specialized exceptions so that when the program crashes on bad input, the stack trace is a little more informative. Your job in Part 2 will be to add real error handling, and some nice features like the ability to read input from files, which will require still more use of exceptions!

Part 1: Adding Exceptions to our good friend Queue

Download the files Lab09a.java, Queue.java and ModQueue.class:
Note: I am giving you the source code (.java files) for Queue and Lab09a, but only the compiled bytecode (.class file) for ModQueue!

The ModQueue class extends Queue in three ways: 1) Duplicate entries are not allowed. If you try to enqueue a string that's already in the queue, the enqueue is ignored. 2) A method void dequeue(String s) has been added, which dequeues everything up to and including entry String s in the queue. If s is not in the queue already, this could cause problems! 3) A method String dump() has been added, that returns a String that is a comma-separated list of the values in the Queue at that point. Compile the program and run the program for yourself. Here are some example runs: 

~/$ java Lab09a 
> add foo
> add bar
> add goo
> dump
foo,bar,goo
> clearto bar
> dump
goo
> quit

~/$ java Lab09a 
> add foo
> add bar
> dump
foo,bar
> clearto bat
Exception in thread "main" java.lang.NullPointerException
	at Queue.dequeue(Queue.java:16)
	at ModQueue.dequeue(ModQueue.java:5)
	at Lab09a.main(Lab09a.java:17)

~/$ java Lab09a 
> dump
Exception in thread "main" java.lang.NullPointerException
	at Queue$Iter.next(Queue.java:32)
	at ModQueue.dump(ModQueue.java:12)
	at Lab09a.main(Lab09a.java:25)

Your job is to add exceptions to Queue.java so that the output for the second and third example looks instead like this: 

~/$ java Lab09a 
> add foo
> add bar
> dump
foo,bar
> clearto bat
Exception in thread "main" QueueException: dequeue empty queue
	at Queue.dequeue(Queue.java:16)
	at ModQueue.dequeue(ModQueue.java:5)
	at Lab09a.main(Lab09a.java:20)

~/$ java Lab09a 
> dump
Exception in thread "main" QueueException: iterator past end of queue
	at Queue$Iter.next(Queue.java:34)
	at ModQueue.dump(ModQueue.java:12)
	at Lab09a.main(Lab09a.java:28)

Note: These must be "unchecked" exceptions (i.e. the ones that Java doesn't require the caller to catch or re-throw.). Why? Because we can't modify ModQueue.java, and it isn't written to catch these!

Important: You should notice that we are able to make these changes and have everything work, even though ModQueue cannot be changed. In fact, we are doing it without access to the source code, or any way to even just recompile it. That should make crystal clear that we have distance (on the call stack) between where the errors occur (in Queue methods) and where they will ultimately be handled in Part 2 (Lab09's main). The fact that we are able to deal with this shows the strength of this approach to error handling.

Part 2: Handling Exceptions

Create Lab09b.java that has the same basic functionality as the above except:
  1. If -v appears as a command-line argument, the program runs in a "verbose mode", where extra information gets printed out. Exactly what gets printed is explained below.
  2. If an argument other than -v appears as a command line argument, it is treated as the name of an input file. That file should be processed as the source of commands rather than standard in. If the file cannot be opened, the following message should be printed (regardless of mode) 
    File 'foo.txt' could not be opened; switching input to standard in.
    and the source of the commands should switch over to being standerd in.
    Note 1: when the input comes from a file, no "> " prompt should be printed.
    Note 2: now that you know about exceptions, you should be to understand the code we gave you before for opening files: 
    Scanner sc = null;
try { sc = new Scanner(new FileReader(fname)); } 
catch(IOException e) { e.printStackTrace(); System.exit(1); }
    ... and adapt it to this problem.
  3. If a user gives the dump command when the queue is empty, or the clearto with a string that isn't in the queue, the program shouldn't crash. Instead, it should silently continue, except that, in verbose mode, issuing a clearto command with a string that's not in the qeueue should result in the error message "String 'foo' not found!" where, of course, foo should be replaced with the actual clearto string. After printing the error, however the program should continue running as if nothing bad happened. Note: in the clearto case, the queue should be emptied by a clearto command with a string that's not in the queue.
  4. If an end-of-file occurs before a "quit" command is processed, whether because the input comes from a file and the file literally ends, or because there was an end-of-file from standard in (e.g. the user pressed control-d), the program should do the following:
    • if the previous command has been completely processed, the program should exit just as if the "quit" command has been given
    • If the previous command has not been completely processed, e.g. if the previous command was add and the end-of-file occurred when trying to read the string to be added, the program should print the message "Unexpected end of input.".
    You need to think about what method would be throwing the exception if the input ended while trying to read the next string.
  5. Invalid commands (i.e. commands other than quit, add, dump and clearto) should be ignored in non-verbose mode, but in verbose mode should give the error message "unknown command 'foo'.", where "foo" should be replaced by the given command. In both cases the program should simply continue to process new commands.
One rule: You may not use the .empty() method on Queue or ModQueue objects! I'm forcing you to use exceptions.

Example: stdin Example: stdin Example: non-existent file, switch to stdin Example: ex1.txt Example: ex2.txt 
~/$ java Lab09a 
> add cat
> add dog
> clearto rat
> dump
> ctrl-d
 
~/$ java Lab09a -v 
> add cat
> add dog
> clearto rat
String 'rat' not found!
> dump
> ctrl-d
 
~/$ java Lab09a -v asdf 
File 'asdf' could not be opened; switching input to standard in.
> add cat
> add dog
> damp
Unknown command 'damp'.
> dump
cat,dog
> quit

~/$ java Lab09a ex1.txt 
foo,bar,bat,cat
bat,cat

~/$ java Lab09a -v ex2.txt 
foo,bar
String 'cat' not found!
Unexpected end of input.

Submitting the lab

You need to submit this properly. We won't track down your missing pieces or your otherwise improperly submitted labs. Here's all you need to do.
  1. Make sure all your .java files are adequately commented, especially with comments that include your name and alpha.
  2. Cd to the directory in which your lab files lie, and give this command: 
    submit -c=IC211 -p=lab09 *.java