Mock 3 exam wrong answer (Java OCA 8 Programmer I Study Guide)

[Vincent Botteman]

One of the questions is about what exception can fill in the blank line to make the code compile.

class LimpException extends Exception{}
class HurtException extends LimpException{}
public void run(){
        try{
            split();
        }
        catch (HurtException e){}
        catch (_____________){}
    }
private void split() throws HurtException{}

In the answer option D (LimpException) is said to be incorrect because the method split throws HurtException and no other exception. Therefore catching LimpException would be unreachable code because HurtException is already caugth.
But I can compile following code, so answer D is correct. I do receive a warning in my IDE about unreachable code but the source compiles and runs.

public class Mock3ExamHurtException {
    private void split() throws HurtException{throw new HurtException();}
    
    public void run(){
        try{
            split();
        }
        catch (HurtException e){System.out.println("HurtException");}
        catch (LimpException e) {System.out.println("LimpException");}
        catch (Exception e){}
    }
    
    public static void main(String[] args) {
        Mock3ExamHurtException m = new Mock3ExamHurtException();
        m.run();
    }
}

class LimpException extends Exception{}
class HurtException extends LimpException{}

[Roel De Nijs]

Vince Botteman wrote:In the answer option D (LimpException) is said to be incorrect because the method split throws HurtException and no other exception. Therefore catching LimpException would be unreachable code because HurtException is already caugth.
But I can compile following code, so answer D is correct. I do receive a warning in my IDE about unreachable code but the source compiles and runs.

First of all, I completely agree with you about answer option D: it should be a correct answer because if LimpException fills in the blank, the code compiles successfully (although with a warning but that's not a compiler error) and you can run the program as well.

But you have to be very careful: there's a huge difference between "unreachable code" and "dead code"! The first one results in a compiler error, the latter one only in a warning. So on the exam, you'll have to know the difference between both, because with dead code the compiler will successully compile the code (and thus you can run the code); but when it detects unreachable, it gives a compiler error and you won't have a .class file (and thus you can't run the code).
To illustrate consider these 2 code snippets

// dead code
try { split(); }
catch (HurtException e) { System.out.println("Hurt"); }
catch (LimpException e) { System.out.println("Limp"); } // compiler warning

// unreachable code
try { split(); }
catch (LimpException e) { System.out.println("Limp"); }
catch (HurtException e) { System.out.println("Hurt"); } // compiler error

The distinction between "unreachable code" and "dead code" is sometimes very hard. So you'll find plenty of threads on this forum about this topic (most of them with lots of examples). E.g. here, here and here.

So the explanation in the book mentions that Java recognizes the LimpException as dead code (which is correct), but dead code is only a compiler warning not a compiler error. So answer D is correct! And finally (pun intended ), I must say I'm a little bit surprised with the compiler warning you'll get when you compile the Mock3ExamHurtException class:
Mock3ExamHurtException.java:10: warning: unreachable catch clause
catch (LimpException e) {System.out.println("Limp");}
^
thrown type HurtException has already been caught
1 warning
It mentions "unreachable" so that could be very confusing and misleading, because unreachable code is a compiler error (and here you'll get a compiler warning).

Hope it helps!
Kind regards,
Roel

[Jeanne Boyarsky]

You're right! Added to the errata. I was so sure that LimpException wouldn't work that I didn't actually try it. Our tech editors must have been as well. Trying it now, I totally agree.

I gave you both a cow for this one. Because this wasn't a typo or slip of the mind. I really didn't think it would work.

[Roel De Nijs]

A similar example with 2 classes from the Java API: FileNotFoundException extends IOException. Given this method declaration

private void doRiskyThings() throws FileNotFoundException {}

this code snippet compiles with a warning

try {
    doRiskyThings();
} catch (FileNotFoundException e) {
} catch (IOException e) {
}

And what do you think will happen when you compile the previous code snippet after you have changed the method declaration to

private void doRiskyThings() throws IOException {}

Will it still successfully compile? With or without warnings?

[Vincent Botteman]

I think the code will not compile because FileNotFoundException is a checked exception and FileNotFoundException is not a superclass of the class that is declared to be thrown by the method (i.c. IOException). So the compiler will detect that FileNotFoundException or a subclass will never be thrown in the try block.

[Roel De Nijs]

Vince Botteman wrote:I think the code will not compile

Wrong! The code compiles successfully, even without any warning. So it's perfectly valid code.

[Jeanne Boyarsky]

Roel: That's evil!

Vince: The reason is that doRiskyThings() declares IOException. The actual implementation is free to throw IOException, any subclass of IOException, any runtime exception or no exception at all. Since it is possible for method to throw a FileNotFoundException, the code is legal.

[Vincent Botteman]

Thanks to all for the clarification. It takes my knowledge of exceptions one step further.

[Roel De Nijs]

Jeanne Boyarsky wrote:Roel: That's evil!

That's my middle name!

Vince Botteman wrote:It takes my knowledge of exceptions one step further.

Let's see if we can increase this knowledge about exception a little further.

Given this class hierarchy

class FoodException extends Exception {}
class VeggieException extends FoodException {}
class Animal {
    public void eat() throws FoodException { System.out.println("animal"); }
}
class Elephant extends Animal {
    public void eat() { System.out.println("elephant"); }
}
class Tiger extends Animal {
    public void eat() throws VeggieException { System.out.println("tiger"); }
}

which of these methods will not compile and/or not run successfully? And why not?

public void method1() {
    Animal a = new Animal();
    try {
        a.eat();
    } catch (FoodException e) {}
}

public void method2() {
    Animal a = new Elephant();
    a.eat();
}

public void method3() {
    Tiger t = new Tiger();
    try {
        t.eat();
    } catch (VeggieException e) {}
}

public void method4() {
    Elephant e = new Elephant();
    ((Animal)e).eat();
}

public void method5() throws Exception {
    Animal a = new Animal();
    ((Tiger)a).eat();
}

public void method6() throws FoodException {
    Animal a = new Elephant();
    ((Elephant)a).eat();
}

public void method7() {
    Animal a = new Elephant();
    try {
        ((Elephant)a).eat();
    } catch (FoodException e) {}
}

Hope it helps!
Kind regards,
Roel

[Mushfiq Mammadov]

Roel De Nijs wrote:Given this class hierarchy
...
which of these methods will not compile and/or not run successfully? And why not?
...

It is a perfect example, Roel, thanks a lot. I learn new things which I don't know so far but I can't keep all of them in memory from the first time It is interesting that why don't you write study guide about certification?

[Roel De Nijs]

Mushfiq Mammadov wrote:It is interesting that why don't you write study guide about certification?

Writing a study guide from scratch is a very daunting task and that requires a massive amount of time and dedication

[Vincent Botteman]

Hi Roel,

The answers of the quiz:

public void method1() {
    Animal a = new Animal();
    try {
        a.eat();
    } catch (FoodException e) {}
}

It compiles successfully because the checked exception FoodException is caught. No problems at runtime.

public void method2() {
    Animal a = new Elephant();
    a.eat();
}

At compile time the reference a is an Animal. And the exception FoodException is not caught or declared to be thrown. So compile error.

public void method3() {
    Tiger t = new Tiger();
    try {
        t.eat();
    } catch (VeggieException e) {}
}

Similar to case 1: no compile or runtime errors

public void method4() {
    Elephant e = new Elephant();
    ((Animal)e).eat();
}

The reference is cast to Animal and the method Animal.eat throws FoodException which is not caught or declared to be thrown, so compile error.

public void method5() throws Exception {
    Animal a = new Animal();
    ((Tiger)a).eat();
}

The reference is cast to Tiger and the method Tiger.eat throws VeggieException which is a subclass of Exception thrown by method5, so the source compiles. But at runtime it will throw a ClassCastException because the object the reference a is pointing to is not a Tiger object.

public void method6() throws FoodException {
    Animal a = new Elephant();
    ((Elephant)a).eat();
}

The reference a is cast to Elephant and the method Elephant.eat throws no exception. It will compile and run successfully. A method is free to declare to throw an exception without actually throwing it.

public void method7() {
    Animal a = new Elephant();
    try {
        ((Elephant)a).eat();
    } catch (FoodException e) {}
}

This time it fails to compile because the catch block is unreachable.

[Roel De Nijs]

Vince Botteman wrote:The answers of the quiz:

A perfect score! Have a cow for having all the correct answers and providing each time a spot-on explanation

[Chris J Allen]

public void method7() {
    Animal a = new Elephant();
    try {
        ((Elephant)a).eat();
    } catch (FoodException e) {}
}

This time it fails to compile because the catch block is unreachable.

Just to confirm my own understanding, the reason the catch block is unreachable is that the Elephant eat method implementation doesn't throw the FoodException right? Since we know that the compiler knows it is an Elephant reference (due to the Elephant cast), it uses that method implementation to determine that the code block is unreachable.

[Jeanne Boyarsky]

Chris: That is correct! Good explanation.