Community
Participate
Working Groups
2.x The Message class provided by the AST to report errors doesn't contain a unique ID to identify the problem. Now that IProblem is API it would be very useful if we can enrich the message class with a unique ID based on the ones defined in IProblem. This would ease the code of presenting errors to the user in the case were we create a temporary CU in memory to see if a refactoring results in a error. Currently we present the compiler's error message which in most cases is hard to understand.
Looks doable. Jim - any comment?
I don't mean to be contrary, but it feels like adding this API will tend to make things more brittle in the long run. IProblem constants do not specify what the problem is (although the name is mighty suggestive). More importantly, the compiler does not make any promises as to which problem ids are used in which circumstances. Under these conditions, it is difficult for a client to reliably do much beyond substituting one error message for the compiler's. Perhaps we could improve the compiler's error messages and achieve the same result directly. Or are there specific cases where we could exact a stronger guarantee from the underlying compiler?
You are right the the ids defiend by IProblem don't carry enough information to change error messages in general. But the refactoring we are executing adds enough information/context to decide which error messages to change. Consider the example that we rename a local variable and choose a name already in use. The compiler message is "Duplicate local variable `name`". This message is a little bit confusing for the user since he expects something like "A local variable `name` already exists in method". Since we know "what" we are changing, the errors that exists before our change and the position of our new code we have enough information to change the compiler's error message in this case.
We should add a new API which would return a collection of IProblem. We can keep the existing API that returns a collection of Message. This is ok if you don't care about the details of the problems reported during the resolution. Is this ok for you?
Proposed new API method CompilationUnit.getProblems() /** * Returns the list of detailed problem reports noted by the compiler * during the parsing or the type checking of this compilation unit. This * list might be a subset of errors detected and reported by a Java * compiler. * <p> * Simple clients that do little more than log the messages or display * them to the user should probably call <code>getMessages</code> instead. * </p> * * @return the list of detailed problem objects, possibly empty * @see #getMessages * @see AST#parseCompilationUnit * @since 2.1 */ public IProblem[] getProblems() { A note on getMessages should point more sophisticated clients at getProblems.
Fixed and released in 2.1 stream.
Verified.
