On Fri, 28 Oct 2022 22:19:38 GMT, Jonathan Gibbons <[email protected]> wrote:
>> In that comment I'm talking specifically about exception-type type
>> parameters. Consider this interface:
>>
>> public interface MyInterface {
>>
>> static <X extends Throwable> void m(...) throws X { }
>> }
>>
>> Now, you can instantiate `X` like this:
>>
>> MyInterface.<EOFException>m(...);
>>
>> But if you want `m` to declare that it can throw two exceptions, you cannot
>> instantiate `X` like this:
>>
>> MyInterface.<EOFException | FileNotFoundException>m(...);
>>
>> Or like this:
>>
>> MyInterface.<EOFException, FileNotFoundException>m(...);
>>
>> You have to provide one exception type. It can either be a common ancestor
>> of `EOFException` and `FileNotFoundException`; for example, `IOException`,
>> `Exception` or `Throwable`. Or you can pack your exceptions into something
>> else as a cause.
>>
>> Whatever you choose, you won't get transparency and compile-time checking
>> similar to what you'd get if you had this:
>>
>> static void m(...) throws FileNotFoundException, EOFException { }
>
> I don't (yet?) see why that language design issue arises here. It looks
> like you're doing a multi-catch of a series of 4 subtypes of `Failure`, and
> an "other". I don't see where any exception type parameter comes in.
Ah OK, there's one hidden in the signature of the `trySearch` method. Is that
one important?
-------------
PR: https://git.openjdk.org/jdk/pull/10746
