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