Menu
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.throws Throwable, as the rest will be erased by type erasure?And one, not directly related question:
catch(Throwable t), or by the provided Supplier's type; since it can't be checked for at runtime?
867
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.
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.
When an exception is thrown the method stops execution right after the "throw" statement. Any statements following the "throw" statement are not executed.
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.
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.
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.
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.
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.
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.T which is bound to Optional's T Supplier which has a wildcard upper bound of X 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.
139
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
