Why throws away part of the method signature

Question

Why is part of the signature method thrown away. It seems strange to include this. Here is an example where it is on the way.

@Overide public void foo() { throw new UnsupportedOperationException(); } 

If someone sees this method from the outside, he may try to use it without knowing that it is not supported. They will learn it only when they try to run the code.

However, if they can do something similar, they will know by looking at a method that is not supported, and if UnsupportedOperationException does not extend the RuntimeException, they will get a compilation error. EDIT1: But this is not possible because throws are part of the signature, so redefinition will not work.

 @Overide public void foo() throws UnsupportedOperationException { throw new UnsupportedOperationException(); } 

This question is about Javas design, so I know that it can be difficult to answer without the participation of one of the people who work on it and answer it, but I was hoping that maybe this question was asked to them earlier or what could be The obvious reason to explain this is why.

Answer 1

The throws part does not indicate that the method should raise the mentioned exception (s), not even with certain actions. It only reports that the function is allowed for this.

The inclusion of throws UnsupportedOperationException , therefore, does not mean that the method is not supported. In addition, UnsupportedOperationException is a RuntimeException , so the throw method can anyway

Now, for the reason that this is required in the method signature, it all comes down to the possibility of checking exceptions in general. In order for the compiler to decide whether a method can only throw the indicated exceptions, it must be able to decide that the methods it calls cannot throw the thrown exceptions.

This means, for example, that overriding a method means that you cannot add exceptions that could be thrown, otherwise you could violate the ability to verify that the method that calls this method cannot throw anything other than the specified one. Another way would be possible (but I'm not sure if Java supports this) by overriding a method that can throw one that cannot be thrown.

So for example:

 class B { int fubar(int) throws ExceptionA { } int frob(int) throws ExceptionA { return fubar(int); } } class D extends B { int fubar(int) throws ExceptionB { } } 

Now frob indicated, perhaps throw only ExceptionA , but when calling this.fubar it will open the possibility that something else will be selected, but fubar is determined, perhaps only throw ExceptionA . Therefore, D.fubar is an invalid override, as this will open the possibility that this.fubar actually throws ExceptionB , and the compiler cannot guarantee that frob does not throw ExceptionB .

Answer 2

Java has two different types of exceptions: checked Exceptions and unchecked Exceptions.

Unchecked exceptions are subclasses of RuntimeException , and you do not need to add a throw declaration. All other exceptions must be handled in the body of the method either with the try / catch statement or with the throws declaration.

An example for unchecked exceptions is an IllegalArgumentException , which is sometimes used to notify that a method has been called with illegal arguments. No rolls are required.

An example for marked exceptions: IOException , which can be selected by some methods from the java.io package. Either use try / catch or add throws IOException to declare the method and delegate the exception handling to the calling method.