Java Reference
In-Depth Information
Code 12.6
continued
Checking for an illegal
parameter value
public ContactDetails getDetails(String key)
{
if (key == null ) {
throw new IllegalArgumentException( "null key in getDetails" );
}
if (key.trim().length() == 0) {
throw new IllegalArgumentException(
"Empty key passed to getDetails" );
}
return book.get(key);
}
It is well worth having a method conduct a series of validity checks on its parameters before
proceeding with the main purpose of the method. This makes it less likely that a method will get
part way through its actions before having to throw an exception because of bad parameter val-
ues. A particular reason for avoiding this situation is that partial mutation of an object is likely
to leave it in an inconsistent state for future use. If a method fails for any reason, the object on
which it was called should ideally be left in the state it was before the operation was attempted.
Exercise 12.25 Review all of the methods of the AddressBook class and decide whether
there are any additional situations in which they should throw an IllegalArgumentException .
Add the necessary checks and throw statements.
Exercise 12.26 If you have not already done so, add javadoc documentation to describe
any exceptions thrown by methods in the AddressBook class.
Exercise 12.27 UnsupportedOperationException is an unchecked exception defined
in the java.lang package. How might this be used in an implementation of the java.util.
Iterator interface to prevent removal of items from a collection that is being iterated over?
Try this out in the LogfileReader class of the weblog-analyzer project from Chapter 4.
12.4.5
Preventing object creation
An important use for exceptions is to prevent objects from being created if they cannot be placed
in a valid initial state. This will usually be the result of inappropriate parameter values being
passed to a constructor. We can illustrate this with the ContactDetails class. The constructor
is currently fairly forgiving of the parameter values it receives: it does not reject null values but
replaces them with empty strings. However, the address book needs at least a name or phone num-
ber from each entry to use as a unique index value, so an entry with both name and phone fields
blank would be impossible to index. We can reflect this requirement by preventing construction of
a ContactDetails object with no valid key details. The process of throwing an exception from
a constructor is exactly the same as throwing one from a method. Code 12.7 shows the revised
constructor that will prevent an entry from ever having both name and phone fields blank.
 
Search WWH ::




Custom Search