Improving readability of type/casting error messages
cowwoc
cowwoc at bbs.darktech.org
Fri Dec 5 05:03:04 UTC 2014
The "simplified" message I quoted below was technically incorrect, but
hopefully you still got my point. Instead of "expected B to extend
Object" it should have read "expected B to extend Promise<? extends Object>"
The point is, let's do all the variable substitution on behalf of the
user in the summary. Instead of Promise<U#2> the user should be seeing
Promise<? extends Object>.
I would still keep the technical breakdown below (with all that
wonderful U#2 stuff) but the summary should do all the mental gymnastics
on behalf of the user.
Gili
On 05/12/2014 12:02 AM, cowwoc wrote:
> Jon,
>
> There has to be a way to improve this. Look at this error:
>
> The type of <U>thenApply(Function<? super T,? extends U>) is erroneous
> 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
>
> incompatible types: inference variable U#1 has incompatible bounds
> equality constraints: Optional<GetPostalCode>
> lower bounds: Promise<U#2>
> where U#1,T,U#2 are type-variables:
> U#1 extends Object declared in method <U#1>thenApply(Function<?
> super T,? extends U#1>)
> T extends Object declared in class Promise
> U#2 extends Object declared in method <U#2>completed(Executor,U#2)
>
> The existing first line is kind of useless. All it says is "you used
> the wrong type in <method signature>. To find out more, read through
> the highly-technical breakdown below".
>
> Couldn't we replace it with this?
>
> "Invoked thenApply(Function<A, B>) with B =
> Optional<GetPostalCode> but expected B to extend Object"
>
> I don't need you to tell me the method signature in the summary line
> (I can read through the technical breakdown for that). Instead, you
> should focus on describing the actual vs expected values using as
> simple wording as possible. Is that possible?
>
> Gili
>
> On 04/12/2014 9:24 PM, Jonathan Gibbons [via OpenJDK] wrote:
>> Gili,
>>
>> 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
>> the messages.
>>
>> 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
>> provide.
>>
>> That being said, there may well be specific instances where messages can
>> be improved, and we welcome input when you find specific messages that
>> are unclear.
>>
>> -- Jon
>>
>> On 12/04/2014 06:05 PM, cowwoc wrote:
>>
>> > Hi,
>> >
>> > 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,
>> > Gili
>> >
>> >
>> >
>> > --
>> > 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.
>>
>>
>>
>> ------------------------------------------------------------------------
>> If you reply to this email, your message will be added to the
>> discussion below:
>> http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424p209427.html
>>
>> To unsubscribe from Improving readability of type/casting error
>> messages, click here
>> <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=209424&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8MjA5NDI0fDE1NzQzMjEyNDc=>.
>> NAML
>> <http://openjdk.5641.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
--
View this message in context: http://openjdk.5641.n7.nabble.com/Improving-readability-of-type-casting-error-messages-tp209424p209439.html
Sent from the OpenJDK Compiler Development mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20141204/4dda9126/attachment.html>
More information about the compiler-dev
mailing list