Community
Participate
Working Groups
Build 20020621 Win2k If you try to save a method like this: int method() { }
Oops! here's what I meant to say.. int method() { int field = 2; } Try to save this, and a squiggly line appears under "field". The error message says that you forgot to return something. Without looking at the error message, it's somewhat misleading because it's telling you there's something wrong with field, which is not true. I would like to see the squiggly line under the "int" in the method signature. If the squiggly line was meant to go under field, and this isn't a bug, then consider this a request.
Moving to JDT CORE for post 2.0 consideration
Last statement is intended to be blamed. Error positioning need some tuning in this scenario. Not critical for 2.0
Source position issue
We might simply want to tag the method name in all cases. Right now if a method has no statement and its return type is different from void, we tag the method name. It might be more consistent to do this all the time instead of tagging the last statement when a method has statements.
If the line were to go under the entire method signature then that would be ok, because there IS something wrong with what's underlined. Ideally, I think the best place to put it is directly on the return type, because that's where the problem really is. Having the line only on the method name would be better than what we have now, but I think it could be misleading to some. It indicates there is something wrong with the name itself, which is not actually true..
Your last statement is incorrect. The location of the error doesn't prevent the user from reading the error message. And the error message clearly states that the problem is that this method doesn't return the proper type.
We should get more opinions on this.. To everyone I just added: Where would you prefer to see the squiggly line?
I actually prefer the current behaviour. The last statement is at fault because it should be a return statement, or should be followed by a return statement. There's nothing wrong with the method signature, so a squiggly line under the method signature is no more useful than the current behaviour. I think it could be improved in some cases though. For example, if the last statement is a compound statement, it currently underlines the first letter of the statement keyword (if, try, while, etc), but it would be clearer (at least to me) to underline the last simple statement inside the compound statement.
John, this would not be enough. Even if you return from the last statement of a if statement. You might not garantee that all paths are returning the proper type. For example: int method() { boolean b = true; if (b) { return 0; } } Then you end up with the same problem. The guilty statement is the "if", not the last statement of the compound statement. I think that finally the current behavior is not that bad. There is no perfect solution and the error message is really clear. "This method must return a result of type ...". Even if we tag the return type in the method header, it is not better, because there is nothing wrong with the return type.
Ok, non-branching compound statements then ;) I find try blocks are the worst case - it underlines the "t" in try, even though the last expression is nowhere near it. In any case, I have no real problem with the current behaviour.
I guess it depends what you consider to be right, the code or the method signature. It's possible that the programmer wrote 'int' instead of 'void' for return type, and it's also possible that he/she forgot the return type.. but there's no way to know which case it is. I think the problem is that we're forced to put the line on something which is correct.. because the problem isn't that something there is wrong, it's that something isn't there at all.. If no one else has a problem with this behavior we can just throw this PR in the garbage..
Ok, I close it as "WONTFIX" since this is not really a problem and there is no perfect solution for it. We will always find somebody who doesn't like the way we did it <g>.
