Summary: | [compiler] Misleading error message for invalid method call with overloaded methods | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Timothy Mowlem <tmowlem> |
Component: | Core | Assignee: | Kent Johnson <kent_johnson> |
Status: | VERIFIED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | david_audel, Olivier_Thomann |
Version: | 3.5 | ||
Target Milestone: | 3.5 M3 | ||
Hardware: | Macintosh | ||
OS: | Mac OS X - Carbon (unsup.) | ||
Whiteboard: |
Description
Timothy Mowlem
2008-08-22 04:32:08 EDT
Unlikely that we'll change this, but what error message would be less confusing to you in this case ? (In reply to comment #1) > Unlikely that we'll change this, but what error message would be less confusing > to you in this case ? > How about switching the terms to say the typed in method doesn't match methods in the file (far more intuitive IMHO than quoting one of a set of methods as being 'not applicable' for the typed in call which seems the 'wrong way round'. So I suggest one of the following: "The method getSchemaUtils(String, String) does not match any method in the type DatabaseUtils" "The method getSchemaUtils(String, String) does not match any method signature in the type DatabaseUtils" "The method getSchemaUtils(String, String) does not match any method defined in the type DatabaseUtils" "The method getSchemaUtils(String, String) does not match any method accessible in the type DatabaseUtils" To me any of these would be clear and unambigous. As mentioned if only a single method with the same name accessible then mentioning the other method signature explicitly as currently is good, but even in that case is would read much better with terms reversed as in the suggested examples above. To provide you with a bit of context... we actually try to find the method that matches the incorrect message send the 'best'. Obviously its not perfect and not everyone will agree with the method we picked, but in most cases it does a pretty good job at trying to find the method you meant to send. Common user mistakes such as typing 1 parameter instead of 2, or 3 instead of 2, are handled by our best guess so its easy for the user to see what the correct method is. And by listing the 'best guess' in the error message, the user can quickly see that he forgot the last parameter. In your case, we matched the first parameter String & picked (String) as the suggested method, since it appeared you forgot to remove the second parameter instead of getting the type of the first parameter completely wrong (File, String). If our suggestion is off base, then a user just needs to invoke code assist over the message send and he'll be provided with all the methods matching the selector. We prefer to 'try to find' the best guess vs. no suggested method at all, since it gives the user the closest match so he can fix the message send quicker. We're going to stay with our 'best guess' match (as described in the previous comment) instead of no guess at all. Verified for 3.5M3. |