On Fri, 28 Oct 2022 21:59:14 GMT, Pavel Rappo <[email protected]> wrote:
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ThrowsTaglet.java
>> line 578:
>>
>>> 576: // exceptions (i.e. Failure.ExceptionTypeNotFound |
>>> Failure.NotExceptionType),
>>> 577: // so we instantiate it with a general Failure. We then
>>> refine the specific
>>> 578: // exception being thrown, from the general exception we
>>> caught.
>>
>> Really? Are you sure? This is exactly why multi-catch was added. Am I
>> missing something here?
>
> 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.
-------------
PR: https://git.openjdk.org/jdk/pull/10746
