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

[Jan Lahoda]

On 12.2.2018 19:50, Liam Miller-Cushon wrote:
> 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,

Thanks.

> * this will fix JDK-8177436 [2] too

I double-checked, and it indeed fixes that.

> * there's a minor typo in the javadoc
> for DeferredCompletionFailureHandler - "throw the the client code"

Fixed in the updated webrev.

Thanks for the feedback,
     Jan

>
> [1]
> http://mail.openjdk.java.net/pipermail/compiler-dev/2017-March/010883.html
> <http://mail.openjdk.java.net/pipermail/compiler-dev/2017-March/010883.html>
> [2] https://bugs.openjdk.java.net/browse/JDK-8177436
> <https://bugs.openjdk.java.net/browse/JDK-8177436>
>
> On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda <jan.lahoda at oracle.com
> <mailto: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
>     <https://bugs.openjdk.java.net/browse/JDK-8187950>
>     Webrev: http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/
>     <http://cr.openjdk.java.net/~jlahoda/8187950/webrev.00/>
>
>     How does this look?
>
>     Thanks,
>          Jan
>
>