Task 1: Exceptions in Action and Catching Exceptions Locally

Start by running the BankApp class. Using the menu, try option 2 to deposit funds even though no accounts have been created. Note that an error message is displayed, but the program doesn't crash. The program detects that we haven't either created a new account or found an existing account to deposit the funds to. How is this done? Take a look at the code in the BankApp class. The application uses a reference variable, named account, for the current account, which is initially null. Find case 2 of the switch statement in the BankApp class. Note that we've coded the program to try to deposit money into the account, but since the account reference variable is null initially, the JVM (Java Virtual Machine) throws a NullPointerException. We've coded our program to use exception handling to catch this kind of exception, which we handle by displaying an error message to tell the program user what corrective action is needed. (The other catch clause in this try-catch statement will be discussed in the next task.)

Next try option 3 and see what happens; it's not the sort of thing we'd like to happen with our programs! Let's correct that problem in a manner similar to what was done in case 2 of the switch statement. Add add a catch clause so that the program displays an appropriate error message rather than crashing. What we've done is added an exception handler to catch an exception locally, that is, in the same method where the problem occurs.

Now run the program again and check that option 3 gives error messages when the account is null. Then create a new account using option 1. Give an initial balance of $100.11 and an account number of 0. The program will create the new account and now you can try menu options 2 and 3 to deposit and withdraw funds.

Task 2: Throwing Exceptions and Catching them Remotely

We've seen that the JVM can throw exceptions, but our programs can also throw exceptions as we'll now see. Review the code in the constructor in the BankAccount class. What happens if we attempt to make a new account with a negative balance? Give it a try by running the BankApp and doing menu option 1 to attempt to create an account with a negative balance.

What happens? An IllegalArgumentException exception is thrown with a message we've added saying that this cannot be done. Rather than Java's VM throwing the exception, our program does this using a throw statement if a balance less that 0 is given. For this task, add code to the constructor so that a 5 digit account number is required (Hint: What range of values gives a 5 digit number?). If an account number isn't 5 digits, use exception handling to throw an exception similar to what was done for the negative balance. Change the message that is added so that it's appropriate for this problem, then give your code a try to ensure it works as expected.

We catch the exception in the main method of the BankApp class, instead of in the constructor where the problem occurs. When an exception is caught in this manner, that is, in a method other than the one where the problem occured, we call it remote catching. Exceptions can be either caught locally or remotely depending on where it most makes sense to try to resolve the problem.

Our BankAccount class also throws IllegalArgumentExceptions in the deposit() and withdraw() methods to indicate when other problems occur. Review that code for another example.

Show the code you've written so far to your Lab TA.

Task 3: Creating our own Exceptions

So far we've been using the exceptions that are provided by Java, but we can also create our own exception classes! Take a look at the InsufficientFundsException class that we've provided. Note that the class body is quite trivial because we're relying on Java's Exception class to do the work for us. How? In the class header we've put the code extends Exception, which results in our class getting its code from Java's already implemented Exception class (this is called inheriting). All we have to do is choose a name for our new exception class and code a constructor in the pattern like what is shown (which enables our exception class to have messages added like what we did in Task 2).

Let's put this new exception to work. In the BankAccount class's withdraw() method, add code to check if the amount given exceeds the account's balance. If it does, then throw a new InsufficientFundsException. Add a message to the constructor's argument list saying "You can't withdraw more than you have!"

There's one more thing we need to do to this method when we use Exception in this manner. Java gives us two choices, checked exceptions and unchecked exceptions. Exception classes that extend Exception are checked and those that extend RunTimeException are unchecked. Checked exceptions are used for the kinds of things that could still go wrong even if we carefully coded our program (e.g., FileNotFoundException, ArithmeticException). For these, the compiler actually checks that the programmer knows the exception might be thrown by requiring either a throws clause or a catch block in the method(s) that might throw checked exceptions. Since our new exception class is checked, we'll add a throws clause to the withdraw method's header so it looks like this:

    public void withdraw(double amount) throws InsufficientFundsException {

This clause tells the compiler that we know that the exception might be thrown and that the withdraw method won't try to fix the problem. Instead, it throws the exception to the method that called withdraw.

Next, we'll remotely catch this exception in the BankApp's main method. In case 3, add a catch clause to handle this kind of exception. All it needs to do is display an error message along with the exception's message like what was already done for the IllegalArgumentException.

When you've completed this code, give your program a try. Create an account and try to overdraw the balance. You shouldn't be able to! Show your working code to your Lab TA.

Task 4: Reading information from a file

Switch so that your partner is in control of the keyboard

In this task, you will be creating code to read bank accounts from a file. We'll isolate file handling from our other classes by creating a separate class that will handle all file input (and output). Create the new class and named it BankIO. This class will not be instantiable (i.e., it won't have any instance members). The BankIO class has the following two class (i.e., static) methods:

• public static void readFile(String filename, Bank bank)
  This method should create a Scanner object that reads from the given file specified by filename. While there's input left in the file, the method repeatedly calls the readAccount method below that returns a BankAccount object, and add that bank account to the given bank.
• public static BankAccount readAccount(Scanner in)
  This method is used to read in one bank account. It's passed a Scanner object and reads the account number (an int) and the balance (a double) of one line of the file. The method should then create a new BankAccount object and return it.

Recall the pattern of code for reading from a file is:

import java.io.File;
import java.io.FileNotFoundException;
import java.util.Scanner;

... method(...) {

    Scanner in;
    try {
        in = new Scanner(new File(filename));
    }
    catch (FileNotFoundException e) {
        ...
    }

    ...
}

If a FileNotFoundException is thrown, the method should display an error message and return. You may assume the file is in the correct format. In the challenge task below, you'll be improving your code to handle files that are improperly formatted.

Reading from a Formatted File

Often we are required to read information from a file that is in some specified format. The format tells you the order and layout of information found in the file. When doing file processing, we want to be able to read valid files that follow the format specifications (and reject invalid files) For our bank program, each line in a file has two pieces of information; an integer account number followed by a double account balance (for an example, see accounts.txt, which you downloaded earlier). Input files may have any number of lines. To know how many lines are in the file, you can use the hasNextLine() method of the Scanner. For each line, you'll need to separate out the account number and the balance. Here are two ways to do this:

Approach 1:

The easiest way to read information from a file requires that the values be separated by whitespace (i.e., spaces, tabs, newlines). Our file is formatted this way so we'll use the Scanner to read each piece of information separately (i.e., use nextInt() and nextDouble()). This approach works well as long as you're careful with processing the newline, which marks the end of each line.

Approach 2:

If the values in a formatted file are separated by some other delimiter, such as a comma, it is better to read each entire line of the file separately (using nextLine()) and then divide the line into the appropriate pieces. There are several ways to do this, but we suggest using the split method of the String class. Try the following code to get a feel for how split works:

  String line = "sample,line,1,23.32";
  String delims = ",";                //this means that each piece is separated by a comma
  String[] tokens = line.split(delims);  //this divides the line into pieces
  System.out.println("Line contains " + tokens.length + " pieces of information:");

  //print out the tokens array to see what it contains
  for (int i = 0; i < tokens.length; i++) {
      System.out.println(tokens[i]);
  }

  int myInt = Integer.parseInt(tokens[2]);  //now convert the third token to an int value
  double myDbl = Double.parseDouble(tokens[3]);  //now convert the fourth token to a double value
  System.out.println(myInt + ", " + myDbl);

Testing

Create a new class named BankFileTester that creates a Scanner object and asks for a file name from the user. Pass the file name to the readFile method. Test using accounts.txt that you downloaded earlier.

When you've tested that your code is able to read the bank files, show your work to your Lab TA.

Task 5: Writing information to a file

Add a method, named write, to the BankIO class which takes a Bank and a String filename and writes the bank to a file with the given name. The method should make use of the toString method of the Bank class. If a FileNotFoundException is thrown, the method should display an error message and return. Recall to write to a file you use the following pattern:

import java.io.PrintWriter;
import java.io.FileNotFoundException;

... method(...) {

    PrintWriter out;
    try {
        out = new PrintWriter(filename);
    }
    catch (FileNotFoundException e) {
        ...
    }
    ...
}

Testing

Add code to the BankFileTester class which will prompt the user for a file name and then call the write method of the BankIO class. Check that your method worked by looking in your project file. In the Package Explorer window of Eclipse, select the folder for your Bank Lab project, and then press "F5" to refresh the project. You should now see the file name you specified, which you can open to verify it has the correct contents. If contents in the file are incomplete, is there something your forgot to do when you finished using your PrintWriter object?

Show your Lab TA the output file created by your program.

Challenge Task: Bad Input Files

In the time that is remaining in the lab, modify your readAccount method so that it throws an IOException if the line of input being read is invalid. Recall that IOException is a checked exception so you'll need to add a throws clause to the method header. Modify your readFile method so it also throws IOExceptions.

Lastly, modify your BankFileTester program to catch IOExceptions and handle them by displaying an error message and giving the user the opportunity to enter a new filename. Test using accounts.txt and badinput.txt that you downloaded earlier.

Show the work you're able to complete to your Lab TA before the lab ends.