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

Guntis Ozols guntiso at latnet.lv
Thu Dec 27 17:02:47 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!
> > >
> 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.

The only reason I want it to be configurable from API is because these
'Frankenstein' grammar files with target language specific error handling
does not fit with my understanding of separation of concerns.
To my understanding, your code above has nothing to do with your grammar
or any other grammar.

Two things polluting my grammar file which i'd like to factor out are:
- package declarations (should be possible to specify as command line opt.)
- flexible error handling code

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

I believe it does not work as expected if there are lexer predicates,
does it? Also, ANTLRWorks debugger does not work if lexer throws
exception (debugger is unable to attach it's all forgiving error
handler at runtime to work properly)

Guntis



More information about the antlr-interest mailing list