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

[Thomas Brandon]

On Dec 28, 2007 12:32 AM, Guntis Ozols <guntiso at latnet.lv> wrote:

> > I'm not sure recognition exceptions should come out.
> > When there is a problem it should keep going.
>
> Oh NO! Reminds me:
>   expecting zip-file, getting atomic-bomb, exploding anyway...
Actually I think this is (or at least should) be the case in almost
all applications. Bailing at the first error is generally extremely
annoying as you want to see all errors in your input not just the
first error.
>
> > If you wanted to bail out and stop lexing, you
> > must make the invoking parser fail as well.
>
> Sure
>
> > I don't think we should pass a lexical recognition exception
> > on to the parser because it is not an exception for the parser.
>
> It is not for the parser, and therefore should be PASSED TO and
> NOT HANDLED by the parser, UNLESS rulecatch LexerException is
> defined in parser grammar.
>
> By default, if LexerException extends RuntimeException,
> it may even be not mentioned in parser, still cause parse to fail.
>
> >    Does that make sense?
>
> See above :)
>
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.
Though perhaps an inbuilt error-tracking class could be provided to
record all errors that occurred. It seems that a class that records a
list of all the exceptions that occurred would be generally useful and
the basis of any more advanced error reporting system so could be
provided by default (though I could be wrong here). Specifying a rule
catch and re-throwing a custom exception could be used to provide
extra information to be used in the reporting process.

Tom.
> > Ter
>
> Guntis
>
>