Improving readability of type/casting error messages
jonathan.gibbons at oracle.com
Fri Dec 5 02:32:22 UTC 2014
I am sorry you feel the error messages have gotten less readable over
time, because we have put a significant amount of effort into improving
It is certainly the case that the type system has gotten a lot more
complex over the past few releases, and in some of the more complex
cases, it is indeed hard to create readable messages . In particular,
although you can interpret a series of phrases to mean
"this::addProperty returns void but thenApply() expects it to return a type
that extends Object"
that sort of transformation is almost impossible within javac,
especially given that we need to be able to localize the message for the
supported non-English locales.
The current design goal for the messages is to have the message begin
with a short 1-line summary, followed by the code in question, to give
some context, followed by any additional details the compiler is able to
That being said, there may well be specific instances where messages can
be improved, and we welcome input when you find specific messages that
On 12/04/2014 06:05 PM, cowwoc wrote:
> With the addition of lambdas in Java8, I'm running into generics error
> messages more frequently than ever before and the messages have gotten less
> and less readable over time.
> I'll start by discussing a seemingly benign error message:
> incompatible types: bad return type in lambda expression
> Promise<Optional<GetPostalCode>> cannot be converted to Optional
> for this code:
> Promise<Optional<GetPostalCode>> result = current.map(child ->
> // do something
> return Optional.empty();
> }).orElseGet(() ->
> return getPostalCode();
> return result;
> The line triggering the error is: "return getPostalCode()"
> Here's my problem:
> 1. getPostalCode() returns "Promise<Optional<GetPostalCode>>"
> 2. "result" is of the same type.
> 3. Looking at this code, it's not obvious why the compiler is trying to cast
> the output to "Optional"
> I've run across this kind of problem very often. The problem I am referring
> to is not the specific error message but rather the fact that you're forcing
> developers to reverse engineer the compiler in their head to figure out what
> is going wrong.
> Instead of forcing developers to do figure out why the compiler is
> attempting a seemingly wrong cast, couldn't the error message explain it
> explicitly? I don't mind passing extra command-line parameters into the
> compiler to get more verbose explanations, so long as this is possible.
> The second kind of error I am running into is:
> method thenApply in class Promise<T> cannot be applied to given types;
> required: Function<? super PostProperty,? extends U>
> found: this::addProperty
> reason: cannot infer type-variable(s) U
> (argument mismatch; bad return type in method reference
> void cannot be converted to U)
> where U,T are type-variables:
> U extends Object declared in method <U>thenApply(Function<? super T,?
> extends U>)
> T extends Object declared in class Promise
> I don't know about you, but (as a human being) I find this message very hard
> to read. It sounds as if the message was written for computers to parse, not
> people. What the compiler is actually trying to say is that
> "this::addProperty returns void but thenApply() expects it to return a type
> that extends Object".
> Is it possible for someone to investigate improving these messages?
> Thank you,
> View this message in context: http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424.html
> Sent from the OpenJDK Compiler Development mailing list archive at Nabble.com.
More information about the compiler-dev