The classes ASTProblem and ProblemKind represent errors/warnings that occur in the math parser.
To be able to use these parsing results in different kind of tools it is necessary to be able to access the cause of the problem and the position of the problem separately.
At the moment only the position is available as a SourceLocation object.
The cause is available via the enumeration ProblemKind. Although the enumeration distinguishes between different types of problems, it offers no way to access the internal cause, but retrieving a formatted string. Unfortunately this string contains the position information.
Logged In: YES
user_id=2134715
Originator: YES
Examples:
Parser input: "var≔1+1asdf"
Error message: "Syntax error at 7:11: invalid Term"
Parser input: "var≔1+1&"
Warning message: "Lexer error at 7, character '&' has been ignored."
Logged In: YES
user_id=1041912
Originator: NO
The internal cause shall be available as an argument of the ASTProblem, that you can retrieve with the getArgs() method. However, currently it is only a String (as far as I remember) so it might be a little to weak for your needs.
What kind of interface would you prefer ?
Logged In: YES
user_id=1041912
Originator: NO
As a side note, messages contain position information because, some time ago, the user interface didn't show this location information graphically. Maybe that now, this information could be removed from the message string.
Logged In: YES
user_id=2134715
Originator: YES
Thanks for you quick response!
I already noticed that the internal cause is sometimes available as element of the argument list (getArgs() returns the array of arguments). It seems to be always the first element of the array.
Unfortunately the internal cause varies depending on the actual problem kind.
In my example above the syntax error message is derived from "Syntax error at %2$d:%3$d: %1$s". In this case the first argument is filled in with the internal message "invalid Term".
The lexer error message is derived from "Lexer error at %2$d, character '%1$s' has been ignored.", with the first argument being "&".
When using the first argument as an error message this would result in the (obviously not helpful) message: "&" ;-)
Sure, I could map each ProblemKind to a corresponding own error message, but would just be a workaround IMHO. The next tool using the parser would have to the same again.
It would be great to be able to access the string describing the error cause without any information about the positions.
Possible methods could be:
getCause() - Returning the error description (without position information)
getSourceLocation() - Returning the location
getMessage() - Returning the complete error description with position (could also be the toString() method)
Logged In: YES
user_id=1041912
Originator: NO
Fabian,
what is your genuine need? Do you want to be able to analyse the problems programatically? Or do you just want to get rid of the positions in the error messages?
Logged In: YES
user_id=2134715
Originator: YES
I want to get rid of the positions because they are only valid relatively in the currently examined predicate or action.
As I'm writing a textual editor for EventB this (relative) position information is not helpful for the user. In addition the Eclipse concept of markers already visually highlights the position of the problem.
Logged In: YES
user_id=1041912
Originator: NO
Locations in error messages where a temporary fix which is not needed anymore as GUIs can display locations graphically and thus in a more efficient way. They soon will disappear.
Logged In: YES
user_id=2134715
Originator: YES
Great! ;-)
This has been fixed and committed to CVS in July this year.