Menu

#205 ASTProblem: No separation between cause and position

closed-fixed
5
2008-11-02
2008-07-03
Fabian
No

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.

Discussion

  • Fabian

    Fabian - 2008-07-03

    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."

     
  • Laurent Voisin

    Laurent Voisin - 2008-07-03

    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 ?

     
  • Laurent Voisin

    Laurent Voisin - 2008-07-03

    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.

     
  • Fabian

    Fabian - 2008-07-03

    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)

     
  • Laurent Voisin

    Laurent Voisin - 2008-07-03

    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?

     
  • Fabian

    Fabian - 2008-07-03

    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.

     
  • Laurent Voisin

    Laurent Voisin - 2008-07-03

    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.

     
  • Fabian

    Fabian - 2008-07-04

    Logged In: YES
    user_id=2134715
    Originator: YES

    Great! ;-)

     
  • Laurent Voisin

    Laurent Voisin - 2008-11-02
    • status: open --> closed-fixed
     
  • Laurent Voisin

    Laurent Voisin - 2008-11-02

    This has been fixed and committed to CVS in July this year.

     

Log in to post a comment.