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

Johannes Luber jaluber at gmx.de
Wed Dec 26 04:10:53 PST 2007


Terence Parr schrieb:
> 
> On Dec 25, 2007, at 1:25 PM, Johannes Luber wrote:
> 
>> Can you give an example to explain the difference between both
>> situations and why the differentiation makes sense?
> 
> The new situation will be that any syntax error, no viable alternative
> for mismatched token, will throw an exception which is caught at the
> bottom of the rule.  The catch clause will report an error and initiate
> error recovery.

That's where I hit my limits of understanding. What error recovery can
be done at the bottom of a rule anyway?

>  As an option, and the default for pre 3.1, you can have antlr try to
> recover within the rule. This is where it does its single token
> insertion or deletion.  If you forget a ')', for example, it often can
> continue within the rule.  This often results in much better error
> recovery.  Per my previous e-mails, this can cause trouble for actions
> that expected that previous token to be matched.  Imagine an action that
> references $ID but the ID did not actually get matched! The parser
> inserted one magically, but it has useless data.

That's really bad.

>> nextToken() catches RuleMismatchException (could be another kindof
>> exception), so it doesn't declare that it throws RuleMismatchException.
>> But there are instances, where someone wants overwrite nextToken() with
>> rethrowing the exception - and can't.
> 
> Hmm...well, I just looked and it seems like it will cause a ripple
> effect where you have to put the catch clause everywhere. It should be
> okay as most of the references are within a parser rule, but don't you
> think it is simply easier to throw either an error or run-time exception
> if you want the entire parsing process to stop upon lexical error.
> 
> Throwing a recognition exception from a token stream is undefined. Who
> is supposed to catch it? you might not even use a parser? I'm not sure
> recognition exceptions should come out.  When there is a problem it
> should keep going.  If you wanted to bail out and stop lexing, you must
> make the invoking parser fail as well. I don't think we should pass a
> lexical recognition exception on to the parser because it is not an
> exception for the parser.
> 
>   Does that make sense?

It makes sense from your point of view. But does this mean, you would
solve the problem described in the XQuery report under 7.7.2 via a
run-time-exception?

Johannes


More information about the antlr-interest mailing list