No-overload-matches error messages are unhelpful #11106
Comments
|
I think it would be helpful if the error report looked like this: Overloads are:
|
|
Maybe another (additional?) option could be to colorize the matched or mismatched args, and to sort the list so that the closest matches can be seen directly, without having to scroll through the less relevant ones. |
|
As it happens, I'm red-green colorblind, and this is true for around 8% of European-descended males. I can still see Crystal colorization for the most part, but differentiating red and green text is often difficult. In the interest of such people, and the more visually handicapped, it would be nice if color would be used to highlight, but would never be the sole means of receiving information. |
straight-shoota
added
status:duplicate
topic:compiler:semantic
and removed
status:duplicate
labels
|
This is a duplicate of #8179 but I'm keeping this newer issue open becaus it's more substantial already. |
|
In a terminal, maybe we could use other text highlighting than color. For examole, all unmatched arguments and parameters (thise are the ones you care about) could be underlined. |
|
w.r.t red/green output in terminals - obviously colour shouldn't be the only way of showing information, but in case anyone wasn't aware your terminal emulator almost certainly lets you go in and re-map what colour "red" and "green" display as (even to completely different colours!). So you may be able to make things a little bit easier to differentiate (when viewing git diffs, etc). |
|
When column type/name was not correct in avram, the output compilation error is hard to read. e.g. The output content like this: If we can output instead of like this (add newline after comma), readability more easily. |
|
@zw963 formatting would be helpful, but I think it's essential that any error report tell you what's wrong directly, not obliquely, if that is at all possible. So, my problem with it saying "I can't match to this long list of arguments" is that it is oblique, and requires the programmer to perform the final step of matching a failing method call to a method prototype. This is laborious in the case of Avram, because the argument list is every field of an arbitrarily long record. So, I reiterate my candidate for a direct, not oblique, error report. Matched: company_id, location_id, ...* This should not require any additional information, like a color key, to interpret. There is also the issue of the steep Crystal learning curve. The learning curve isn't about the Crystal language. It's about how to connect an error message to the location of the actual error through the many layers of code that are reported. Thanks Bruce |
|
I think the "Matched", "Did not match", "Required but not provided" might be a bit too verbose. Maybe it's just enough to show one error per overload, because if no overload matched then there's always an error in each of them. For the initial example, I'm thinking about an output like this: The messages might not be exactly those, but that's the general idea. What do you think? Other such messages, for each overload, might be:
Then if an error happens in all of the overloads... say for example all overloads have a |
|
If the compile can capture the programmer intention, that is okay. the issue is, afraid compiler give info which guide the programmer to the wrong indirection. anyway, from my point of view, current Overloads output is okay, it just need pretty print. |
|
@zw963 could you provide an example of how would that look with pretty print? |
|
@asterite why not put the "Argument X doesn't exist" and other such messages above the method prototype instead of below it? @zw963 wished to break at commas, his example is here: #11106 (comment) Finallly, I wish there was some way to hide |
|
There is often one method prototype, yet the example you provided has like five overloads. So I think we should consider that case if you want your specific example to improve. |
|
Yes, Avram is the worst case we have so far. But the example I gave repeats every prototype twice as both |
Okay, a more robust way is, when union type is more longer, not easy to read, print all overload union type's argument on separate line. e.g. following error message is really hard to read, and find the column out. (see screenshot)
We can add a As so, we can find the columns as describe in error message (in this case, is password, password_digest, licenses_allowed_creation_times), and thought on why this error happen. We don't make decisions what wrong here, we just pretty print all overloads here, let use to figure it out. (more easiler) |
|
@BrucePerens , i prefer to only add newline instead give exact error message like "Matched", "Did not match", "Required but not provided", because i consider that not so useful.
|
I consider this is not a good idea, that exactly avram want us to know. |
|
Well, Billy, you are obviously an achieved computer scientist. And you comprehend these complexities and even relish them. I would ask you to have some sympathy for the newbie. For them, the error reports of crystal are mainly incomprehensible. And that has driven a tremendous gap between Ruby and Crystal that has thrown a barrier before Crystal adoption. Although the two languages appear very similar, the difference becomes evident when one confronts a compiler error report. Ones like this are simply incomprehensible to the newbie and require a significant learning curve. Indeed, I have some achievement in this world and still find many of them challenging. So I really strongly request that we always have the newbie in our minds when we code error handling. |
This is a common sort of error message I get when creating a model instance using the Avram ORM. It's extremely difficult to isolate what is actually wrong here. It would be much better if the compiler would tell, for each potential overload match, which arguments matched and which did not.
https://github.com/luckyframework/avram
The text was updated successfully, but these errors were encountered: