Community
Participate
Working Groups
Build ID: 3.5M1 I20080807-1402 Steps To Reproduce: 1. Create a class with overloaded methods, eg A(String, String) and A(File, String) 2. Instantiate the class and call A(String) which is an error as A(String) is not defined 3. Error message shown by popup message (in yelllow 'tooltip') is misleading More information: I have two methods as follows: getSchemaUtils (File f, String s) getSchemaUtils (String s) I mistakenly called getSchemaUtils(String s, String t) and a compile error was shown. The error message displayed was: "The method getSchemaUtils(String) in the type DatabaseUtils is not applicable for the arguments (String, String)" The error message is misleading because it implies that there is only a single other method with the same name when there are in fact two. The error message is fine is there is only a single method of the name, but when two or more methods of the same name exist then the error message should be more generic and not mention a single method out of a set of such methods as this is confusing.
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.
