COMP 2100 Lab Exercise 3: Exceptional Payments
(12 points)
Turn in before the next lab session.

Introduction

You will implement and test two classes for simple processing of loan payments.

1. Payment represents a payment consisting of account number and payment amount. Click the class name to see its API.
2. PaymentProcessor includes methods for simple entry and processing of payments. Click the class name to see its API.

The major objective of this assignment is to get some experience in generating and handling exceptions.

Specifications

1. Note that the stub versions of the classes already include all comments including Javadoc. You do not need to modify the comments, other than to add your name at the top of both classes.
2. The provided PaymentDriver class includes main() along with code to test the Payment amd PaymentProcessor classes pretty thoroughly. It has an optional Run Argument (activate in jGRASP by selecting Run Arguments in the Build menu). Run argument "i" (no quotes) will invoke PaymentProcessor's inputNewPayment() method, which cannot be tested automatically since it involves interactive user input. NOTE: This is the only way to test inputNewPayment(). I suggest you keep it for last, but don't forget to do it!
3. Run PaymentDriver on the code as provided. It will pass 3 tests and fail 18.
4. Do a simple implementation of the Payment class. Assign parameters to instance variables in the constructor and return them in the getters. After you've done this correctly, PaymentDriver will pass 7 tests and fail 14.
5. Once you've done the previous step, all the basic functionality of Payment and PaymentProcessor is correct. In other words, they will work correctly if given valid input and argument values. Everything else you do in this exercise concerns exception handling.
6. All constructors and methods whose API includes one or more Precondition: clauses must throw an IllegalArgumentException that includes a string describing the problem if any precondition is not met. Because this is an unchecked exception, you do not need a throws clause in the method signature.
7. Every method must meet its API specifications.
8. Notice that the Payment constructor must enforce preconditions on both the format of the account ID and on the amount.
9. The account ID can be validated using methods provided by the String, Character and Integer classes.
10. The PaymentProcessor method inputNewPayment() will ask the user to input payment information using JOptionPane. It must use the Payment constructor to validate user input (by catching any exceptions it throws), rather than performing all the input validation itself.

Scoring

To Turn In