RFR: 8285488: Improve DocFinder [v4]
Jonathan Gibbons
jjg at openjdk.org
Fri Oct 28 22:27:20 UTC 2022
On Fri, 28 Oct 2022 21:59:14 GMT, Pavel Rappo <prappo at openjdk.org> 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
More information about the javadoc-dev
mailing list