Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Error handling #28

Closed
keleshev opened this Issue May 2, 2013 · 5 comments

Comments

Projects
None yet
2 participants
Contributor

keleshev commented May 2, 2013

I know that error handling is on the todo-list, but I just wanted to point out that it is the only reason I still don't use parsimonious for production code. I really want to make a docopt version using parsimonious, but just can't afford to show no errors to my users. Otherwise parsimonious is great and fast.

Also check out this thread: http://www.reddit.com/r/Python/comments/1dfqqo/write_an_interpreter_in_python/

Owner

erikrose commented May 2, 2013

Ah, I didn't realize you were the docopt guy! Kudos. I've been admiring docopt from afar for months—it's a wonderful idea, and I'd love to see a version based on parsimonious. Error handling is the next thing I'm working on, probably even before I finish benchmarking. (I've got a benchmarking branch started locally, but I keep getting hung up on parse errors on my sample input from mockJSON—error reporting is a prerequisite to everything, it would seem!)

In the meantime, I've been using some ugly, makeshift error reporting sort of like PyParsing gives. I've just stuck this code into Expression.match():

    if cache is None:
        # The packrat cache. {(oid, pos): Node tree matched by object `oid`
        #                                 at index `pos`
        #                     ...}
        cache = {}
    expr_id = id(self)
    node = cache.get((expr_id, pos), ())
    if node is ():
        node = cache[(expr_id, pos)] = self._uncached_match(text, pos, cache)

    # Debugging output:
    if node is None:
        print self, "doesn't match at", repr(text[pos:pos + 20])
    else:
        print self, 'matches', repr(node.full_text[node.start:node.end])

    return node

It doesn't help your users, but I put it here in case it helps you debug any grammars in the interrim.

Thanks again for prodding me; error reporting is next!

Owner

erikrose commented May 6, 2013

I think I've figured out the outlines of how this should work. If I don't encounter any unpleasant surprises, I should be able to bang out an implementation the next time I sit down to work on it. It should give you enough to report to your users. Later will come crazy visual tracing and debugging.

Contributor

keleshev commented May 6, 2013

Sounds good. I already have a branch where I try to use parsimonious: docopt/docopt@78b8aea

If you are interested you should participate in issue discussions, for example this one: docopt/docopt#104

@erikrose erikrose closed this in f498d06 May 8, 2013

Owner

erikrose commented May 8, 2013

You should be able to take a pretty good shot at a docopt version that uses Parsimonious now. I'll be adding line and column attrs to ParseError soon, and those will help you customize your error presentation if you so desire. Can't wait to see what you come up with.

Contributor

keleshev commented May 8, 2013

Great, thanks! line, column is about as good as you normally get from parsers :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment