Exception Bug

The Exception class itself is a checked exception (as anything not in the RuntimeException hierarchy should be). That's fine, but if I create a subclass of Exception, call it NewException, and then I use it with an empty try block:

code:

try {

} catch(NewException e) {

...

}

compilation fails with "exception NewException is never thrown in body of corresponding try statement". But if I use Exception itself:

code:

try {

} catch(Exception e) {

...

}

it compiles fine. Why is the behavior different between these two checked exceptions?

Ans: 1

The Java compiler warns about catch blocks that couldn't possibly be entered. Note that RuntimeException is a subclass of Exception, and there are a large number of RuntimeExceptions that can be thrown by virtually any code -- NullPointerException, ArrayIndexOutOfBoundsException, etc. Therefore a catch for Exception is almost always applicable.

Now, it's true, actually, that the compiler cheats a little; I'm pretty sure an empty try block can't throw an Exception (it can throw a Throwable, though: ThreadDeath is just one example.) The Java Language Spec doesn't seem to say anything about this (Jim, you listening?) But in any case, the catch block for Exception can catch the whole family of RuntimeExceptions, which needn't be declared, and therefore, in theory, can be thrown by any code.

Ans: 2

I think it does say something - it says the compiler is in error here. [shocked] The relevant section is JLS2 14.20:

"A catch block C is reachable iff [...] some expression or throw statement in the try block is reachable and can throw an exception whose type is assignable to the parameter of the catch clause C."

The same text is found in the JLS3 beta, section 14.21.

It seems that in order for a catch block to be reachable, the try block must have at least one expression or throws statement. Thus the catch blocks in both of Joseph's examples is by definition unreachable, and the compiler is required report a compile-time exception here. Since it doesn't (in the second case, anyway) I would say that the compiler does in fact violate the spec here. Unless I've missed something somewhere of course...

This does not seem to be terribly significant for any practical application, since there's really no use that I can see for ever having an empty try block anyway. It probably would've been better if they'd just considered an empty try block (or finally block) to be a compile-time error. I suppose JLS3 is still in development; maybe one of us should report this earth-shattering news to them so they can fix it.

Ans: 3

Normally, the compiler guards against catch blocks that can never be entered. But there (apparently) comes a point where that's just not practical.

It's virtually impossible for the compiler to predict what type of code might throw any type of Exception (including RuntimeException). So basically, the compiler will "look the other way" and let a catch(Exception) block pass, even if the associated try block is empty.

On the other hand, your own class, MyException, is much more specific, so it's much more reasonable for the compiler to check for code that might throw an instance of MyException.

Ans: 4

It is figured out as a bug which will have its explanation in next release of Java Language Specification.

Example:

import java.io.IOException;

public class Test {

public static void main(String[] args) {

try{

System.out.println("Checked Exception: " );

}catch(IOException ex){

System.out.println("Exception Caught: " + ex);

}

}

}

Output: Compile time error.

Test.java:10: exception java.io.IOException is never thrown in body of corresponding try statement

}catch(IOException ex){

^

1 error