RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure.

[Liam Miller-Cushon]

On Wed, Feb 14, 2018 at 7:33 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Today, I got an idea that might solve this issue without too much hassle,
> sketched here:
> http://cr.openjdk.java.net/~jlahoda/8187950/webrev.01-ext/
>
> Will need more testing, but possibly could work. Any opinions/ideas?


Thanks - that fixed the first two regressions I saw. I'm not sure whether
getKind() was the only instance of this problem, but I'm running more tests
and will report back.

One thing I'd like to point out is that this can (AFAIK) happen even now -
> if the interface B is completed in a way that will throw away the
> CompletionFailure (e.g. Elements.getTypeElement), then the subsequent code
> will AFAIK see the same state as this AP sees. So it seemed somewhat
> acceptable to let the behavior be similar in case where the
> CompletionFailure would be thrown, esp. since I didn't see a good way to do
> better.
>

Good point. I guess I've seen more issues around processors catching completion
failures and leaving the model in a bad state for other processors (or
javac), than around the completion failure itself causing problems. It's
important that processors can detect when they're seeing invalid input. If
they end up needing to be more vigilant about checking for error types
that's a slightly incompatible change.

There was some discussion in JDK-8187950 about declaring an exception in
the API contract for methods that currently throw completion failures. Did
you consider taking that approach, and having the completion failure be
rethrown to ensure other processors and javac see it if they try to
complete the same symbol? Maybe JDK-8190054 answers that question - it
sounds like there's a preference for returning error objects instead of
throwing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180214/8cefa725/attachment.html>