Q on Exceptions: catch/declare java.lang.Throwable

[Gian Franco]

Hi,

Given the following code:

abstract class WLP6Q61_A {
String s = "hello";
abstract String getStr() throws Throwable;
}
class WLP6Q61_B extends WLP6Q61_A {
String s = "hi";
String getStr() throws Exception {if(true) throw new Exception("hi");
return s;}
}
class WLP6Q61 {
public static void main (String[] s) throws Exception {
WLP6Q61_A obj = new WLP6Q61_B();
System.out.print(obj.s + obj.getStr());
}
}

The compiler complains with the following:


WLP6Q61.java:13: unreported exception java.lang.Throwable;
must be caught or declared to be thrown
System.out.print(obj.s + obj.getStr());
^
1 error

Since all checked exceptions are subclasses of java.lang.Exception
why isn't it enough to catch or declare java.lang.Exception. There
are no checked exceptions in the hierarchy in between Exception and
Throwable.

Can anyone explain?

Cheers,

Gian Franco
[ May 20, 2004: Message edited by: Gian Franco Casula ]

[Barry Gaunt]

JLS 8.4.4 says:

A method that overrides or hides another method (�8.4.6), including methods that implement abstract methods defined in interfaces, may not be declared to throw more checked exceptions than the overridden or hidden method.

More precisely, suppose that B is a class or interface, and A is a superclass or superinterface of B, and a method declaration n in B overrides or hides a method declaration m in A. If n has a throws clause that mentions any checked exception types, then m must have a throws clause, and for every checked exception type listed in the throws clause of n, that same exception class or one of its superclasses must occur in the throws clause of m; otherwise, a compile-time error occurs.

But to me your example seems to be doing what JLS says. I'll pass on this one till I've had some sleep

[Corey McGlone]

As far as I know, Throwable, itself, is not considered a "run-time" exception. It's nothing but an abstraction, really. Both Exception and Error descend from Throwable and RuntimeException, of course, extends Exception.

Anyway, because Throwable is not considered a run-time exception, it must be caught.

However, I believe this is a case in which you're trying to figure out a problem by doing something that is inherently wrong. You should never throw an instance of Throwable. Therefore, you should never have to catch one.

I realize that, when studying for the SCJP, we often look at the wrong ways of doing things in order to better understand Java and the right ways to do things, but I think this is one case in which we should step back and look at what we're asking.

[Corey McGlone]

I take back my previous post on grounds that I'm an idiot. I just re-read your code and I think I have a little more insight into this.

Notice the compile-time type of your variable. The compile-time type is WLP6Q61_A. In that method, getStr() throws a Throwable. As the compiler doesn't know what the run-time type of obj will be when this line is executed, it must ensure that you have accounted for ALL exceptions that might arise. As WLP6Q61_A declares that it throws Throwable, we must account for that.

If you change the compile-time type of obj to WLP6Q61_B, the error disappears because the compiler now knows that you have accounted for all possible exceptions.

[Barry Gaunt]

Yes, the two classes WLP6Q61_A and WLP6Q61_B are OK. Because of the polymorphic call through obj, it is required that main declares or catches the exception declared to be thrown by the base class WLP6Q61_A (Throwable).

Or like Corey said in his second post (he's no idiot - I guess he's just got up)

[Gian Franco]

Thanks

Gian Franco