[antlr-interest] Development of an XQuery parser with full-text extensions, project report

Guntis Ozols guntiso at latnet.lv
Thu Dec 27 07:30:30 PST 2007


> > I think the current handling is good,  I think in most cases the most
> > sensible thing to do is to record errors but keep parsing so this
> > should be the default. It should (as I believe it currently is) be
> > easy to throw a runtime exception on error to abort parsing.
> > (...)
> > Tom.
>
> It's not good. It should be possible to attach error-listener/handler
> to lexer/parser from API, and recover if this listener/handler says so
> (for example, recover from first 100 errors), otherwise fail.
> If there is no listener/handler - fail!
>
> Will you be hapy with a database tool which happily deletes all rows from
> the table because of misspelled where clause (on the way, printing humble
> error message somewhere on the server console),
> what kind of reliability is that?

I also think that the question
- How do I report more than one error?
is the question of improvement, but
- How do I stop it from accepting invalid input?
is call for help and indication of trap
not expected from a serious tool and/or tool generator

Guntis



More information about the antlr-interest mailing list