CS51 - Fall 2009 - Lecture 32

  • http://www.cs.cmu.edu/~dst/DeCSS/Gallery/Debate/sld024.htm

  • 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
       - 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 behavior, 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
       try
       {
          // 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

  • How can we improve the user experience?

  • Hierarchy of exceptions
       - Exception
       -- RuntimeExeption
       --- IndexOutOfBoundsException
       ---- ArrayIndexOutOfBoundsException
       ---- StringIndexOutOFBoundsException
       --- IllegalArgumentException
       ---- NumberFormatException
       
       - This is the inheritence hierarchy (i.e. extends)

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

  • multiple catch blocks
       try
       {
          // 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
       }

  • show IntelligibleColorMixer demo

  • show IntelligibleColorMixer code

  • 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 readLine() 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)

  • 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

  • Spelling lab
       - work in pairs
       - Design!

  • General announcements
       - 51 grader/mentor
       - CS Pizza break (Thursday 6pm 1st floor of Edmunds)
       - File I/O for TP2