Skip to content

Better error reporting #29

ieure opened this Issue Dec 13, 2013 · 2 comments

3 participants

ieure commented Dec 13, 2013

One of the things I've found challenging with moderately complex parsers is getting a clear handle on their failure modes. There are a number of things about Parsatron that make debugging challenging.

  1. Errors include the line and position of the input, but doesn't tell you about the parser in error. When dealing with a complex parser which calls other complex parsers, it is hard to determine which one is causing the error.
  2. The way (either …) merges errors makes it hard to even see what the cause of the problem was. For example, this simple parser:

    (run (choice (char \A) (char \B) (char \C)) "abcdef")

    Produces this awful error:

    java.lang.RuntimeException: Unexpected token 'a', Unexpected token 'a', Unexpected token 'a', Error at line: 1 column: 1

    It includes the message from every parser which failed, even though the messages are identical, which obscures what is actually going on. At the very least, it should filter the messages so they are distinct, but I think the behavior is questionable, period.

  3. It would be terrific if the line of input which parsing failed on was printed on failure. It can be hard to orient yourself without this context. I know Parsatron can parse structured data, but the assumption that lines of text are the source is already baked in (#24). May as well make the assumption worthwhile, I think.

youngnh commented Dec 16, 2013

All of your points are well-taken. I don't disagree with any of them, but I'm not sure I can devote much time to fixing them until after the new year. At that point, I think the whole project needs a roadmap to plan out some much-needed active development.

Thanks for using the library and providing points for improving it.

bwo commented Dec 2, 2014

AIUI, edward kmett's trifecta library ( doesn't attempt to show informative error messages like that unless you explicitly give your parser a name using the <?> combinator, which isn't necessarily the most user-friendly thing for the writer of the parser but might make it a lot easier for parser consumers. (I'm not at all sure I do understand it, though.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.