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