Logo Questions Linux Laravel Mysql Ubuntu Git Menu

throws x extends Exception method signature


Reading the JavaDoc of Optional, I bumped in a weird method signature; I never saw in my life:

public <X extends Throwable> T orElseThrow(Supplier<? extends X> exceptionSupplier)                                 throws X extends Throwable 

At first glance, I wondered how the generic exception <X extends Throwable> is even possible, since you can't do that (here, and here). On second thought, this starts to make sense, as it is here just to bind the Supplier... but the supplier itself knows exactly what type it should be, before generics.

But the second line hit me:

  • throws X is a complete generic exception type.

And then:

  • X extends Throwable, what in the world does this mean?
    • X is already bound in the method signature.
  • Will this by any means, solve the generic exception restriction?
  • Why not just throws Throwable, as the rest will be erased by type erasure?

And one, not directly related question:

  • Will this method be required to be caught as catch(Throwable t), or by the provided Supplier's type; since it can't be checked for at runtime?
like image 867
Mordechai Avatar asked Jun 10 '15 14:06


People also ask

Is throws exception part of method signature?

Common checked exceptions are IOException and SQLException. Checked exceptions must be listed in the throws part of the method signature if you don't handle them yourself.

What does add exception to method signature mean?

If a method declares an exception in its signature, you cannot use this method without handling the exception - you can't compile the program. Example 1: The program did not handle the exception declared, resutled in compilation error. import java. util. Scanner; import java.

Does throwing an exception end the method?

When an exception is thrown the method stops execution right after the "throw" statement. Any statements following the "throw" statement are not executed.

What happens when a method throws an exception?

When a method declares that it throws an exception, it is not required to handle the exception. The caller of a method that throws exceptions is required to handle the exceptions (or throw them to its caller and so on) so that the flow of the program can be maintained.

How do you handle exceptions in a method signature?

One way to overcome this problem is by using throws like this: declare the exceptions in the method signature using throws and handle the exceptions where you are calling this method by using try-catch.

What does it mean when a method throws an exception in Java?

throws throws is a keyword in Java which is used in the signature of method to indicate that this method might throw one of the listed type exceptions. The caller to these methods has to handle the exception using a try-catch block.

Why unsupportedoperationexception should be in the signature of a method?

Besides the UnsupportedOperationException is a RuntimeException so a method may throw that anyway. Now for the reason one would require it in the signature of the method, it boils down to the ability to have checked exceptions at all.

What does it mean when a method throws unsupportedoperationexception?

The throws part does not indicate that the method is required to throw the mentioned exception (s), not even at particular occasions. It only tells that the function is allowed to do so. Including throws UnsupportedOperationException will consequently not mean that the method is unsupported.

Video Answer

1 Answers

Treat it like any other generic code you've read.

Here's the formal signature from what I see in Java 8's source code:

public <X extends Throwable> T orElseThrow(Supplier<? extends X> exceptionSupplier) throws X 
  • X has an upper bound of Throwable. This will be important later on.
  • We return a type T which is bound to Optional's T
  • We expect a Supplier which has a wildcard upper bound of X
  • We throw X (which is valid, since X has an upper bound of Throwable). This is specified in JLS 8.4.6; so long as X is seen as a subtype of Throwable, its declaration is valid and legal here.

There is an open bug about the Javadoc being misleading. In this case, it's best to trust the source code as opposed to the documentation until the bug is declared fixed.

As for why we're using throws X instead of throws Throwable: X is guaranteed to be bound to Throwable in the uppermost bounds. If you want a more specific Throwable (runtime, checked, or Error), then merely throwing Throwable wouldn't give you that flexibility.

To your last question:

Will this method be required to be caught in a catch(Throwable t) clause?

Something down the chain has to handle the exception, be that a try...catch block or the JVM itself. Ideally, one would want to create a Supplier bound to an exception that best conveyed their needs. You don't have to (and probably should not) create a catch(Throwable t) for this case; if your Supplier is type bound to a specific exception that you need to handle, then it's best to use that as your catch later up in the chain.

like image 139
Makoto Avatar answered Sep 23 '22 18:09