Exercise 12.4

The use of many different utility classes is actually quite good. The alternative would have been to write our own similar functionality, and that would be a waste when it is already there.

A HashMap does not have the method tailMap() which is used in the search() method, so we can not replace the TreeMap with a HashMap.

Exercise 12.6

It would be more appropiate to calculate the value. If we calculate the value, we don't have to remember to increase and decrease the value.

One example where it fails is if we accidently put in the same contact details twice, then it would incorrectly increment the numberOfEntries twice.

Exercise 12.7

It throws an error:

java.lang.NullPointerException
at AddressBook.removeDetails(AddressBook.java:119)

Exercise 12.10

The modified method:

    public void removeDetails(String key)
    {
        ContactDetails details =
                        (ContactDetails) book.get(key);
        if(details == null) {
            return;
        }        
        book.remove(details.getName());
        book.remove(details.getPhone());
        numberOfEntries--;
    } 

Exercise 12.11

It depends... but it might be a good idea to report the error, as it is likely that the the client of the removeDetails actually thought that the key was there.

It could be reported with a return value which could be checked by the client.

Exercise 12.12

See section 12.2.2 in the book.

Exercise 12.13

getDetails and keyInUse does not result in any errors no matter what arguments we give them.

Exercise 12.18

Yes, the output should be different. The graphical version should pop up a window and the text based version should print out a string.

Exercise 12.19

Yes, at least one of the arguments name and phone should contain a valid string. If both of them are null or empty there is no key available to look up the adress.

Exercise 12.20

No. A search for something should be expected not to find any matches.

Exercise 12.21

A constructor can not return any values to indicate an error. One way it could be solved is to use unchecked exceptions which is discussed in the next section of the book.

Exercise 12.22

CharConversionException
EOFException
FileNotFoundException
InterruptedIOException
InvalidClassException
InvalidObjectException
IOException
NotActiveException
NotSerializableException
ObjectStreamException
OptionalDataException
StreamCorruptedException
SyncFailedException
UnsupportedEncodingException
UTFDataFormatException
WriteAbortedException

Exercise 12.23

SecurityException is an unchecked exception.

Exercise 12.24

See the project address-book-v3t.

Exercise 12.28

This is bad for at lesat two reasons:

1. It is catching all Exceptions (even unchecked exception are caught). It should be more specific.
2. It does nothing in the exception handling block.

Exercise 12.30

All exceptions are caught by the the first catch and it will never reach the error handling for unchecked exceptions (RuntimeException)

Exercise 12.31

All exceptions are caught by the the first catch and it will never reach the error handling for unchecked exceptions (RuntimeException)

Exercise 12.34

testForAdditionError() results in an assertion failure.

Exercise 12.35

Yes, it should have a consistency check because we might change something into a key that already exists, and thereby decreasing the count.

Exercise 12.36

It fails at the consitentSize assertion in the removeDetails becuase it does not remove entry which uses the address as the key.

Exercise 12.37

If you could change the phone number of a ContactDetails the phono number used as key in the book is no longer correct. This could result in problems in the methods that uses the phone number as the key.

Exercise 12.38

See: http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html

Exercise 12.39

You can use the method isDirectory() on the File object.

Exercise 12.40

Not much is available about the contents of a file through the File obejct. However, you can get the size of the file in bytes via the method length().