Interface declaration with unverified or checked exceptions

Question

I searched for a potential answer to my question below and did not find it.

I understand the difference between checked and unchecked exceptions, as well as what a programmer can / should do with them. However, I don't quite understand how the compiler interprets unchecked exceptions when it comes to interfaces.

Recently, I have been programming an interface and implementation similar to the following:

public interface Operation { int operate(int x, int y) throws ArithmeticException; } public class Divide implements Operation { @Override public int operate(int x, int y) throws ArithmeticException { try { return x / y; } catch (ArithmeticException ex) { System.out.println("Division error!"); } } } 

Here where I am confused. The following implementation will also be implemented:

 public class Divide implements Operation { @Override public int operate(int x, int y) { return x / y; } } 

Why doesn't it matter to the compiler that I declared the method as an exception exception in the interface? I understand that Unchecked Exceptions are Runtime Exceptions exceptions and that the programmer does not need to handle them, but I don’t understand why, when I explicitly specify in my interface that I want the processed exception not to force me to handle it.

Can someone give an explanation why the compiler will resolve this situation?

Answer 1

You are misleading the "handling" of an exception with inheritance rules. When you implement or override a method, there is no rule that the new method should throw the same exceptions as the implemented / overridden method. The only rule is that it cannot throw a checked exception that goes beyond the allowed exceptions for the parent method. Think of the interface as creating a contract with the outside world. It says: "Anyone who calls this method should be prepared to handle these types of exceptions." Then developers can throw an exception, knowing that it will be handled, but they should never throw it.

Answer 2

The runtime exception declaration in the throws available for information only (and javadoc) so that users of your class / interface know what to expect in this situation.

Since they are executable, the compiler does nothing for them — neither catch nor declare.

Answer 3

In addition to the previous answers, it is worth noting that this code is great for noted exceptions:

 interface Translator { String translate(String s) throws IOException; /* <-- Checked exception */ } class EnglishGermanTranslator implements Translator { @Override public String translate(String s) { // <-- no exception, but its ok return ""; // logic is irrelevant... } } public class Test { public static void main(String[] args) { EnglishGermanTranslator t = new EnglishGermanTranslator(); t.translate("Text to translate"); // No problems... } } 

But when we reference the EnglishGermanTranslator via Translator , we have to catch the corresponding exception:

 public class Test { public static void main(String[] args) { Translator t = new EnglishGermanTranslator(); t.translate("Text to translate"); // <-- compilation error... try-catch required (or throws in main) } }