2

I understand that catching a checked exception that is never thrown in the corresponding try block is invalid. Because the compiler itself would have forced the programmer to handle the exception if it was to occur.

For example, this code snippet -

try
{
}
catch(IOException e)
{
}

is invalid.

But why doesn't the compiler work the same way for the method that throws a checked exception that has never been thrown in the body of the method?

For example, this code snippet -

void test() throws IOException
{
}

is surprisingly valid.

Please explain the reason behind it. TIA.

Syed Zabi Ulla
  • 81
  • 7
  • Does this answer your question? https://stackoverflow.com/questions/35184092/why-is-catching-checked-exceptions-allowed-for-code-that-does-not-throw-exceptio – nehacharya Mar 02 '21 at 08:09
  • Not exactly. It emphasizes more on catching checked exceptions. My question is regarding declaring checked exceptions that are never thrown. – Syed Zabi Ulla Mar 02 '21 at 08:37
  • 1
    Methods have to be allowed to declare they throw an exception, even if they don't actually throw it, because overriding methods (may) declare that they throw checked exceptions that the base class method throws. And overrides of those methods may need to throw the exceptions. – Andy Turner Mar 02 '21 at 09:18

4 Answers4

3

Because you might want to allow subclasses to throw this exception.

public abstract class Parent {
  public void doStuff() {}
}
public class Child {
  // this is illegal, because you throw more exceptions than the overridden method
  public void doStuff() throws IOException {}
}

This is even more intuitive for interfaces, the (non-default) methods of which will never throw an exception but can declare it.

daniu
  • 14,137
  • 4
  • 32
  • 53
1

It is a compile-time error if a catch clause can catch checked exception class E1 and it is not the case that the try block corresponding to the catch clause can throw a checked exception class that is a subclass or superclass of E1, unless E1 is Exception or a superclass of Exception.

This tells you all these are valid:

try { }
catch(Exception e){}

--

try{ }
catch(NullPointerException  e) {}

--

try{ }
catch(ArrayIndexOutOfBoundsException  e) {}

--

try{ }
catch(RuntimeException e) {}

--

try{ }
catch(Error e) {}

--

try{ }
catch(Throwable e){ }

It's not related to a void block. It's related to an impossible path to your checked subclass of Exception.

What happens with subclasses of Exception? For example IOexception: Those are unreachable catch blocks. Nothing in the try block can lead to that exception, so the compiler just tells you: this block would never be executed, as it would never catch that subException.

The difference with throws: The concept of unreachable code doesn't exist in this context. The possibility of a method throwing an exception doesn't end in the deffinition of the method. For example:

abstract void readFile(String path) throws IOException;

This method doesn't even have a block, as it's an abstract method. It's easy to guess that this line won't ever throw any IOException. But it defines a behaviour for the extensions that will implement it. In order to override it, your method must throw the IOException.

In the same way, if someone overrides your test method:

@Override
void test() throws IOException
{
   readFile(file);
}

It's not impossible to happen, in contrary to your first try-catch block.

aran
  • 10,978
  • 5
  • 39
  • 69
1

Java follows the rule "handle or declare".

If there is a checked exception declared in your code, you must handle it (in a try/catch block) or declare it (adding 'throws' on method signature).

When you say your method may throw an exception, everyone using your method must handle or declare that exception. If you handle it, you are making your code capable of recovering. If you declare it, you are passing the problem to the caller.

The compiler is fine if you declare 'throws', he knows what to do when your method will be called.

If you declare an exception that is not actually there, you are making users of your code aware that, in a future release, you may add that exception. Users will be prepared for the day you will add that exception.

Siberio
  • 105
  • 9
0

Specifying says that method can throw an exception or can not throw. But compiler don't check it, because he can't, actually. So try block only check specifying. The point is compiler don't see deference between actual calling exception and method's specifying. If you call test() in try block, it'll valid. Sorry for my English)