[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