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

[Liam Miller-Cushon]

Hi Jan,

I've run into the same problem a few times, and made some half-baked
experiments around not caching completion failures [1]. The approach you
describe sounds good to me. Also,
* this will fix JDK-8177436 [2] too
* there's a minor typo in the javadoc for DeferredCompletionFailureHandler
- "throw the the client code"

[1] http://mail.openjdk.java.net/pipermail/compiler-dev/2017
-March/010883.html
[2] https://bugs.openjdk.java.net/browse/JDK-8177436

On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Hi,
>
> Currently, when a calling some API methods, the client (e.g. TaskListener,
> an annotation Processor or a JavacTask client) may get a CompletionFailure,
> if the given Symbol was not completed yet. This is not only problematic for
> the clients, but if the client catches and ignores the exception, the javac
> may be unable to report an appropriate error.
>
> The proposed patch here:
> -separates "user " and "javac" modes, in which CompletionFailure handling
> differs a bit
> -in javac mode, CompletionFailures should be handled as they are currently
> -in user (code) mode, when a CompletionFailure is thrown (and would go
> outside of an API method), the API method will suppress the exception, and
> the Symbol's state (completer, kind, type) will be restored to original
> when the mode is switched back to javac mode. If the Symbol is then
> completed again inside javac, the CompletionFailure is thrown again and the
> appropriate errors are reported.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187950
> Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/
>
> How does this look?
>
> Thanks,
>     Jan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180212/46d15bcf/attachment.html>