Exceptions

Exercises

1. We typically ask you to start each set of lab exercises by running the corresponding lablet, and that is what we'll do here. Unlike previous labs, though, we want you to try to induce errors into this lablet's processing by entering some nonsensical data, and by omitting some necessary data, rather than just modifying the applet's code.
   
   
   1. First, compile and run OrderPlease as you would if you were using it to order merchandise from Monty's Musical Madness. Enter realistic data for all of the information requested, and submit your order.
      
      
   2. Clear the order form by clicking the Reset button. Then, try the following operations. Record what happens in each case, and refer to the program listing to explain why.
      
      
      1. See if you can add -5 (that's negative 5!) Harmonious Harmonicas to your new order.
         Result:
         
         
         
      2. Enter "abc" as a quantity for a "Going Going Gong," and try to add that item to your order.
         Result:
         
         
         
      3. Add some legitimate items to an order, but leave some information, like the credit card number, blank. Try submitting the order.
         Result:
         
         
         
   3. Let's edit the program to remove one of its exception handling sections, and then re-run the program to see what the exceptions are preventing.
      
      
      1. Comment out the try-catch clauses in function processAddItemButton() leaving only the statements:

            int quantity = Integer.parseInt(custQuantity.getText());
            doAddItem(quantity);
         

      2. Compile and run the edited program.
         
         
      3. Enter "two" as the quantity for any item, and try to add that item to your order. What happens?
         Answer:
         
         
         
2. Make the following edits to the original version of the lablet, one at a time. For each, try to compile and run the revised applet, recording what happened and why.
   
   
   1. Remove the argument "ex" from the line in function processAddItemButton() that reads:
      catch (NumberFormatException ex)
      Result:
      
      
      
   2. Change the line in function processAddItemButton() that reads:
      catch (IllegalQuantity ex)
      to read
      catch (Ilegalquantity ex)
      Result:
      
      
      
   3. Replace the statements in the actionPerformed() method:

         try
         {
            processSubmitButton();
         }
         catch (MissingData ex) // Some data was missing
         {
            order.appendText("*** " + ex.getMessage() + CRLF);
         }
      

      with
      processSubmitButton();
      Result:
      
      
      
   4. Remove the phrase throws IllegalQuantity from the header of function doAddItem()
      Result:
      
      
      
   5. Change the header of function processSubmitButton() to read:
      private void processSubmitButton() throws MissingData
      Result:
      
      
      
3. Even with OrderPlease's current level of exception handling, it still doesn't take much to submit an order that is bogus for one reason or another. Let's make some extensions to the applet in the interest of plugging some of the remaining security gaps. In each case, you will have to:
   
   
   • define a new Exception subclass,
     
   • decide where instances of the exception should be thrown,
     
   • decide where to catch the exception, and finally,
     
   • determine what processing should be done when the exception is caught.
     
     
   1. The original lablet allows one to enter any data at all for a zip code. Fix the program so that it will not submit an order that does not have a legal zip code. For our purposes, we'll assume that any integer in the range of 10000-99999 could be a legal zip code.
      
      
   2. The original applet asks the user to specify an expiration date for the credit card being used. Unfortunately, an expired card is accepted just as readily as an active one. Fix the program so that it will not submit an order unless the credit card expiration data is some time in the future. To simplify things, we'll assume that all that is to be entered into this field is the year of expiration (in full numeric form, like 2003), and that any card with a year that is greater than or equal the current year is acceptable.