RFR: JDK-8187950: javax.lang.model APIs throws CompletionFailure or a subtype of CompletionFailure.
cushon at google.com
Mon Feb 12 18:50:01 UTC 2018
I've run into the same problem a few times, and made some half-baked
experiments around not caching completion failures . The approach you
describe sounds good to me. Also,
* this will fix JDK-8177436  too
* there's a minor typo in the javadoc for DeferredCompletionFailureHandler
- "throw the the client code"
On Mon, Feb 12, 2018 at 4:43 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev