Head First Java 2nd Edition Page 332

[Shawn Lo]

Dear All:

I am reading Head First Java 2nd Edition Page 332, and I have a question.

Paragraph 2, "A ShirtException catch is big enough to take a TeeShirtException or a DressShirtException(and any future subclass of anything that extends ShirtException)."

I think A ShirtException catch is a big enough to take a TeeShirtException AND a DressShirtException. TeeShirtException and DressShirtException both extend ShirtException, so ShirtException should be big enough to take both TeeShirtException and DressShirtException. But, Since TeeShirtException already has a unique exception for itself, it will not go in ShirtException.

I am confused here. Could anyone help me?

Thank you.

[Adam Nace]

I found your discription of the question a bit confusing (and I haven't read Head First Java), but I can tell you this much:

Exceptions are objects.

Just as you can store an instance of a subclass in a reference to the superclass, you can store an instance of a subclass of an exception in an instance of the superclass exception.

Thus, if you say: throws ShirtException, this means that the method can throw ANY type of ShirtException, including TeeShirtException, DressShirtException, BlouseException, TankTopException, TubeTopException, HockeySweaterException, etc...

Similarly, if you say: catch(ShirtException e), this means that this particular catch block can be entered if the try block threw ANY type of ShirtException, including TeeShirtException and DressShirtException.

Furthermore, since a ShirtException is a subclass of Exception, you could choose to insteas as: catch(Exception e), which would catch ANY type of ShirtException, but also NullPointerException, ClassCastException, NumberFormatException, IndexOutOfBoundsException, IOException, ClassNotFoundException, InterruptedException, etc, etc, etc.

It works exactly like any other class heirarchy.

I hope this helps.

- Adam

[Campbell Ritchie]

Go into the API, and look for the class Throwable, then go to Exception. Look at the list of "direct known subclasses" for each of them, then from Exception follow through a couple (eg RuntimeException, and IOException). Write down an upside-down tree with a few names of Exceptions on, and then see which Exceptions inherit (are subclasses of) [from] which other Exceptions. Only do it for a few, unless you have a very large sheet of paper. Look at those Exceptions in the API, and see their hineritance trees.

Look at the inheritance of ArithmeticException, for example.
If you use

try{somethingOrOther}
catch(ArithmeticException ae)
{
   doSomething;
}
catch(RuntimeException rte)
{
   doSomethingElse;
}
catch(Exception ex)
{
   doSomethingDifferent;
}

Your ArithmeticException will be caught by the 1st "catch." It will not be caught by the 2nd or 3rd catches, because it has already been caught. You can't catch the same Exception twice, unless you re-throw it. If you get a different type of RuntimeException (eg ArrayOutOfBoundsException), it will fall to the 2nd catch, and any other kind of Exception (eg IOException) will fall to catch(Exception ex).

If, however, you write this sort of thing:-

try{somethingOrOther}
catch(Exception ex)
{
   doSomething;
}
catch(RuntimeException rte)
{
   doSomethingElse;
}
catch(ArithmeticException ae)
{
   doSomethingDifferent;
}

, your ArithmeticException will AGAIN be caught by the first catch. In fact, every type of Exception will be caught by the 1st catch, and the other two will sit there idle with nothing to catch, for ever.
Bad news, if you require different handling for ArithmeticException.
See, an ArithmeticException "is-a" RuntimeException, which "is-an" Exception. Your catch blocks will catch any Exceptions they catch, AND, any subclasses thereof.

So, your "ShirtException" catch will catch "TeeShirtExceptions," "DressShirtExceptions," as well as "NightShirtExceptions," but not TrousersExceptions.
More realistically, if you extend ArithmeticException to produce DivideByZeroException and IntOver2147483647Exception (seeInteger.MAX_VALUE in the API for the 2147483647 bit), both of those Exception "are-an" ArithmeticException, so both will be caught by the 1st catch block in each code snippet I posted.

That help you at all?
Does this bit of the Java tutorial help?
CR