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

[Thomas Brandon]

On Dec 28, 2007 2:30 AM, Guntis Ozols <guntiso at latnet.lv> wrote:
>
> > > 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!
> >
I can't really see why you'd generally want to do that rather than do
the whole parse and then only print the first 100 errors. There are
some cases sure, but I don't see any need to complicate ANTLR dealing
with them. Currently you can do something like:
@lexer::members {
  int numErrors = 0;
  public void reportError(RecognitionException e) {
    if(numErrors++ > 100)
      throw new TooManyErrorsException();
    }
  }
}
Where TooManyErrorsException is a RuntimeException subclass. I don't
see any general need to have error handlers specified at runtime,
though of course you can add this if you need it.

> > 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?
That's got nothing to do with ANTLR, that's the application's problem.
As I said, I thought having a default error handler that collected
errors rather than simply printing them to the console would be a good
idea then they can be analysed and appropriate, application specific,
steps can be taken. Obviously ANTLR can't know which errors should
lead to aborting and which shouldn't and I think in most cases
aborting on any error is not what you want and you should complete the
parse and based on errors received decide on what further processing
to do. I don't think that the reportError should be removed, but I
think overriding it to throw a runtime exception is a perfectly good
way of aborting on any invalid input and I don't see any reason to
make it any easier by complicating ANTLR.
>
> 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
As I said, I think completing a parse with erroneous input is
generally desired, as in every compiler, database application and
pretty much every other parser based tool I have used, they all print
all errors not just the first one, hence you don't want to abort the
parse.
>
> Guntis
>
>

Tom.