CS51 - Spring 2010 - Lecture 21

  • http://www.youtube.com/watch?v=VczbbiRmDik

  • Exercise 16.5.9

    Write a method that takes an array of words (i.e., Strings) as a parameter and returns true if and only if the array is in alphabetical order. Mixed case (i.e., both lower and upper case) can be used in the words, so be sure to take that into account. You may assume that the array is completely filled; there are no empty entries in the array.

  • CS62 registration: add yourself to the PERM list (wait list). It's very, very likely we'll increase the class size and let everyone in (within reason :)

  • TP2: Centipede
       - extra credit: put list of EC in comments at top of CentipedController class
       - grading
          - 100 points total
          - like TP1 must to some extra credit to get 100 (this time, just 2 points worth)
          - up to 5 additional points of EC
          - 60 points come from just the style and design!
          - incremental design
             - much better to turn in good quality code that implements most of the functionality than bad code that implements everything
       - code quality
          - be careful not to introduce bad coding style with your extra credit
          - review the notes on 11/1 about common style mistakes

  • show FragileColorMixer demo
       - what can go wrong here?
          - user can enter something that's not a number
             - NumberFormatException
          - user can enter something not in the range of 0 to 255
             - IllegalArgumentException

  • what other exceptions have we seen?
       - NullPointerException
       - ArrayIndexOutOfBoundsException
       - StringIndexOutOfBoundsException
       - ArithmeticException (e.g. divide by zero)

  • show FragileColorMixer code
       - how can we fix this?

  • show SaferColorMixer code
       - we can try to check ourselves
          - write a method:

          private boolean isInteger(String s)

       - What's annoying about this?
          - the other methods are already checking for problems and letting us know with an exception
          - we don't want to have to check this again
          - requires us to know things about the Color class!
          - hard to have some default behaviors, like, keep the current color if an error occurs

  • show AlmostIntelligibleColorMixer demo

  • show AlmostIntelligibleColorMixer code
       - rather than checking ourselves, we can "catch" exceptions
       - allows us to react to issues without having to explicitly check for them
       - Exception is a class!

  • try-catch blocks
          // code that may throw an exception
       }catch(<exception_class_name> <variable_name>){
          // code to run if an exception of type <exception_class_name> occurs

  • general things to mention
       - exceptions are classes
          - they have member methods for accessing data
          - getMessage()
          - getStackTrace()
       - when an exception is thrown, any code after where the exception is thrown until the catch statement will NOT be executed
       - Hierarchy of exceptions
          - Exception
             - RuntimeExeption
                - IndexOutOfBoundsException
                   - ArrayIndexOutOfBoundsException
                   - StringIndexOutOFBoundsException
                - IllegalArgumentException
                   - NumberFormatException
          This is the inheritence hierarchy (i.e. extends)

  • the reason the AlmostIntelligibleColorMixer code works is that both IllegalArgumentException and NumberFormatException are both of type "Exception"

  • How can we improve the user experience?
       - we'd like to have different error messages for different issues/exceptions

  • multiple catch blocks
          // code that may throw an exception
       }catch(<exception_class_name1> <variable_name1>){
          // code to run if an exception of type <exception_class_name1> occurs
       }catch(<exception_class_name2> <variable_name2>){
          // code to run if an exception of type <exception_class_name2> occurs

       - see if the exception matches the first catch statement, if not, goes on
       - what would happen if we had switched the order of the catch statements?

  • show IntelligibleColorMixer demo

  • show IntelligibleColorMixer code
       - what would happen if we changed the first catch to catch "Exception"?
          - code won't compile because we cannot reach the second catch statement
          - every IllegalArgumentException is an Exception

  • show StupidName demo
       - reads and writes output from the console
       - We've seen how to write it out: System.out.println()
       - We can read it in using System.in.read();
          - sits there waiting for a character to be read (process/program is "blocked")
          - when it does, returns that single character
          - reads it as an int, so we type cast it to a char
          - char nextChar = (char)System.in.read();
       - We want to write a method public String readName() that uses System.in.read() and reads the line entered by the user (in our case the name)
       - How can we do it?

  • look at StupidName code
       - try it without try-catch block
       - compiler complains: "Unhandled exception type IOException"
       - StringBuffer class
          - remember, all String operations create a new String
          - if we're doing a lot of concatenating (e.g. one character at a time), very wasteful
          - StringBuffer is a mutable class
          - It's literally a long array of characters, some entries of which are unused (this type of data structure in CS is called a buffer)
       - Why did I use a StringBuffer here instead of a String?

  • checked vs. unchecked exceptions
       - The exceptions we've seen previously are called unchecked exceptions
          - we don't need to handle them if we don't want to
          - this checking is NOT enforced by the compiler
          - any exception that inherits from RuntimeException
       - All other exceptions are called checked exceptions
          - we must handle them
          - they are checked by the compiler and if they are not handled, a compiler error will occur

  • we have two options for dealing with checked exceptions
       - we can put a try catch block around the code
       - or, we can say that we don't want to deal with it here and announce to the world that our method throws that exception
       - we do this by appending: "throws <exception_class_name>" after the method description before the '{'

  • throwing exceptions
       - two reasons why a method is required to announce that is throws a particular exception
          - a method it calls throws an exception and the method doesn't handle it
          - the method explicitly throws an exception
       - throw new <exception_class_name>()
          - note it's just a constructor for a class
             <exception_class_name> exceptionToThrow = new <exception_class_name>();
             throw exceptionToThrow;
          - throw is similar to return... exits the current code

  • Look at StupidNameWithThrow code
       - notice that there is no try-catch statement in the readName class
       - However, since readName() now throws a checked exception (IOException) we need to have a try-catch block in the begin method around where we call readName()

  • show StupidNameWithBadName demo
       - how can we do this?
          - We could modify readName(), but what should we return if there is a problem?
          - We could modify our begin method to check if the name is good, but then we'd have to check that any place where we called the readName method
          - Use an exception
             - We can define our own exceptions by extending Exception
             - look at BadNameException in StupidNameWithBadName code
                - usually end the class name with "Exception"
                - override getMessage() method
                - could in theory extend RuntimeException, in which case it would be an unchecked exception. In general, good coding practice to make all you exceptions checked.

  • look at StupidNameWithBadName code
       - readName now throws two different exceptions
       - we can throw and exception using the "throw" keyword

  • Lab 11: Apples(Hangman)
       - may work with a partner
          - if you need a partner, send me an e-mail
          - I can even pair you up on the day of if you'd like a partner then
          - if you have a partner, you must both be there whenever you are working on the program
       - may not use arrays to store the letters