CSC 224: Program 4 Part II

Objective of this Program: (a) Working with arrays of objects, (2) and handling bad input (exception handling).

This program is a continuation of Part I, and will complete the program.

This method will be the only method you will write for this assignment. However, because it is a fairly complicated method, you must break it up into auxilary private methods. If you do not add extra private methods, points will be taken off. I used 3 extra methods to implement it. Remember a good rule of thumb is that no mehtod should take more than one page to print out (about 65 lines of code (LOC)).

You will be given a text file of data to be processed. It will consist of one transaction per line. Each transaction will have at least 3 parts, and one (transfer) will have 4 parts. The data will be of the format

accountNumber codeForTransaction amountOfTransaction

E.g.

1000  1   80
1001  2  90
1002  3  85  1006

1	deposit
2	withdraw
3       transfer

So for each input line from the data file, you will 'decode' it and then carry out the required transaction. Each successful transaction will change the values of an account (or two if a transfer).

It will keep on reading data until there is no more data to be read. One way to test for this is using the readLine method of of BufferedReader:

BufferedReader input;
String line;
.
.
.
while((line =input.readLine()) != null )

Each transaction is to be processed. If it is done successfully, it should output to the terminal window via System.out.println that the transaction (give transaction) was successful and the current balance of the account(s) after the transaction. So for example for the transaction 1000 1 80, the result output would be

transaction 1000 1 80 sucessful, new balance is $387.43.

while for the transaction 1002 3 85 1006, the output could be:

transaction 10023 85 1006 successful. new balance of 1002 is $382.43 and new balance of 1006 is $405.78.

If there is bad input data, a message must be writted to the error file and to the terminal window. There are several type of errors you must catch. Some of them will be caught by the software, e.g., the returned value of deposit, withdraw, and transfer is not zero, or, errors are caught by the try..catch clauses for exceptions.

In this extension of Part I, we also want to be able to handle bad input data.If there is bad input data, a message must be writted to the error file and to the terminal window. There are several type of errors you must catch. Some of them will be caught by the software, e.g., the returned value of deposit, withdraw, and transfer is not zero, or, errors are caught by the try..catch clauses for exceptions.

E.g., the input line could be:

1000 1 3a9.87

When we did the Double.parseDouble on the "3a9.87", as this can not be converted into a double, an exception would be thrown. We want to be able to catch the bad data, notify the user that we are not using this input, but continue the program with the next input.

For each of the inputs above (account number, code, or amount), we need to catch them.

We will do this in a try....catch clause in case the data is not a number. It will use a NumberFormatException, which is the exception generated from Integer.parseInt and the Double.parseDouble when using the StringTokenizer class. This exception is mentioned on pge 482 of the text (Section 11.4) and treated the same way as the IOExceptions as discussed in the text. Examples of how to use them have been given in class. If bad data is found, it will signal that via a System.out.println and a message to the error file.

If such an exception occurs, you should write an error message to a file called error.txt, which should exist in the same subdirectory as your project. The error message should print out the transaction and the type of error generated. This could be on one line. so for the ransaction of
1000 1 3a9.87
The output to the error file (and the terminal window) might say Error on transaction 1000 1 3a9.87: bad input, not a number

We want to open this file for appending data. That is to say, if the file exists, we want to add to it and not create a new file.

Note that one can open a file for append via the class FileWriter. So, for example, the following code will create a file called error.txt if it does not exist, but will open it if it does exist. It will then write the String line to the end of the file.

String line;
error = new FileWriter("error.txt",true);

error.write(line+"\r\n");

You can also write a line separator by the following code

error.write(System.getProperty("line.separator");

This is the same as a "\r\n" above, but it is better. Not all systems recognize "\n", but the line.separator will work on all systems.

The value of true in the constructor means to append to the file if it exists. If one gave the value of false, then it would create a new version of the file and destroy any earlier version which existed. We call this clobber when a new verison replaces an old version.

Note:Be sure to close the file error before exiting the method. If you do not do this, you will not have some of the output written to the file when the program terminates.

Because when one is working with arrays, it is so easy to inadvertently get a NullPointerException, you should also handle that case as well via a try...catch clause when appropriate.

You should also handle the ArrayIndexOutOfBounds exception. You will definately be given account numbers out of range of the array of BankAccounts. These exceptions must be caught as well and written to the terminal window and the error file.

You should look at the reference library of all Java classes for more details about these exceptions. Each of them is a class in the API of java.

You should not assume that the transaction code (1=deposit, 2=withdraw,3=transfer) is always correct. You must test for this as well. If an inccrrect transaction code is given, you should output that mistake both to the terminal window and the error file.

Finally, if an account can not make a transaction because of insufficient funds, this should be told to the terminal window. However, it is not a transaction for the error file. The error file only is sent transaction which can not be executed.

When you try and write to the error file, Java insists that you catch the IOException. This is because writing to a file can cause many problems. Hence you will have to do all of your writes inside a try...catch clause.

The main Testing Method

This will be doing what was done in Part I. This does not have to be MODIFIED.

There are the same 2 data test sets as for part I: data to create the data and the other data for the transactions. To make the testing of the program easier, I have given you a set of good data only for the transactions. In this data set, all of the transactions have no errors. You should first write your program to only handle good transactions and test it out with the good datai, goodtransactions.txt. Then add the error-catching facilities and test it out with the transactions.txt set.

Extra Credit

The extra credit consists of the following reading and writing the array as a file of objects and not saving the data in a text file. When one does this, one only needs one line to both read and write the data.

The use of Object I/O is discussed in the handout on files in Section V. However, in the example, I write the file item by item in the array. One can write it (and read it) in just one line of code.

Note that you have to make the BankAccounts to implements Serializeable for this to work.

Finally, you will need to change the main interface by adding another input on the command line. Now, input can come in via two ways:

1. the data is in a text file and we are creating the BankAccount array, which is what you already did in part I.
2. The data in in a binary file and you need to read it in via the ObjectInputStream or some other API. This is what you are doing in the extra credit.

You should post your project as a 'zip' file on the COL website. It should be posted under the appropriate assignment. Also indicate how many hours you worked on the program in the Readme.txt file.

Homepage of CTI School back to 211 homepage