[antlr-interest] Development of an XQuery parser with full-text extensions, project report
Jim Idle
jimi at temporal-wave.com
Thu Dec 27 08:27:05 PST 2007
You are confusing two separate systems altogether. Parsers should
attempt to recover and list all errors that they can. Virtually all
other programs should stop immediately upon fatal errors. Ter suggested
throwing an exception to STOP the parsing completely, hence the small
overhead of throwing a single exception is irrelevant in that case.
Jim
> -----Original Message-----
> From: Guntis Ozols [mailto:guntiso at latnet.lv]
> Sent: Thursday, December 27, 2007 7:00 AM
> To: Thomas Brandon
> Cc: antlr-interest at antlr.org
> Subject: Re: [antlr-interest] Development of an XQuery parser with
full-
> text extensions, project report
>
> > 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?
>
> Guntis
>
More information about the antlr-interest
mailing list