10/01/10
20:20:56 1
15
CS 61B: Lecture 15
Friday, October 1, 2010
Today’s reading: Sierra & Bates, pp. 189, 283.
EXCEPTIONS (continued)
==========
The "finally" keyword
---------------------
A finally clause can also be added to a "try."
try {
statementX;
return 1;
} catch (SomeException e) {
e.printStackTrace();
return 2;
} finally {
f.close();
return 3;
}
If the "try" statement begins to execute, the "finally" clause will be executed
at the end, no matter what happens. This example (which is contrived) always
returns 3; never 1 or 2.
If statementX causes a SomeException, the exception is caught, the "catch"
clause is executed, and then the "finally" clause is executed. If statementX
causes some other class of exception, the "finally" clause is executed
immediately, then the exception continues to propagate down the stack.
"finally" clauses are used to do things that need to be done in both normal and
exceptional circumstances. (Again, closing files is an example.)
In the example above, we’ve invoked the method "printStackTrace" on the
exception we caught. When an exception is created, it takes a snapshot of the
stack, which can be printed later.
It is possible for an exception to occur in a "catch" or "finally" clause. An
exception thrown in a "catch" clause will terminate the "catch" clause, but the
"finally" clause will still get executed before the exception goes on. An
exception thrown in a "finally" clause replaces the old exception, and
terminates the "finally" clause and the method immediately.
However...you can put a "try" clause inside a "catch" or "finally" clause,
thereby catching those exceptions as well.
Exception constructors
----------------------
By convention, most Throwables (including Exceptions) have two constructors.
One takes no parameters, and one takes an error message in the form of a
String.
class MyException extends Exception {
public MyException() { super(); }
public MyException(String s) { super(s); }
}
The error message will be printed if it propagates out of main(), and it can be
read by the Throwable.getMessage() method. The constructors usually call the
superclass constructors, which are defined in Throwable.
GENERICS
========
Suppose you’re using a list of Objects to store Strings. When you fetch a
String from the list, you have to cast it back to type "String" before you can
call the methods exclusive to Strings. If somehow an object that’s not a
String got into your list, the cast will throw an exception. It would be nice
to have the compiler enforce the restriction that nothing but Strings can ever
get into your list in the first place, so you can sleep at night knowing that
your family is safe from a terrible ClassCastException.
So Java offers _generics_, which allow you to declare general classes that
produce specialized objects. For example, you can create an SList for Strings
only, and another SList for Integers only, even though you only wrote one
SList class. To specify the class, SList takes a _type_parameter_.
class SListNode<T> {
T item;
public SListNode<T> next;
SListNode(T i, SListNode<T> n) {
item = i;
next = n;
}
}
public class SList<T> {
SListNode<T> head;
public void insertFront(T item) {
head = new SListNode<T>(item, head);
}
}
You can now create and use an SList of Strings as follows.
SList<String> l = new SList<String>();
l.insertFront("Hello");
Likewise, you can create an SList of Integers by using "SList<Integer>" in the
declaration and constructor.
The advantage of generics here is that the compiler will ensure at compile-
time that nothing but Strings can ever enter your SList<String>, so there will
be no nasty surprises at run time.
Generics are a complicated subject. Consider this to be a taste of them;
hardly a thorough treatment. Sun has a much longer tutorial at
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf .
Although Java generics are superficially similar to C++ templates, there’s a
crucial difference between them. In the example above, Java compiles bytecode
for only a single SList class. This SList bytecode can be used by all
different object types. It is the compiler, not the bytecode itself, that
enforces the fact that a particular SList object can only store objects of a
particular class. Conversely, C++ recompiles the SList methods for every type
that you instantiate SLists on. The disadvantage is that one class might turn
into a lot of machine code. The advantages are that you can use primitive
types, and you get code optimized for each type. (Java generics don’t work
with primitive types.)
