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

Guntis Ozols guntiso at latnet.lv
Thu Dec 27 05:32:14 PST 2007


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

Why catch? You only need to catch lexer/parser predicates,
but predicates are normal flow, and exceptions are slow
so I'd suggest to call special (with flag?) methods for
predicates to maybe return null instead.

> 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

No, errors are intended for more serious problems,
like OutOfMemoryError, StackOverflowError

> or run-time exception if you want the entire parsing process
> to stop upon lexical error.

This must be on by default.
BTW LexerException can extend RuntimeException, too,
to make throws declaration optional.

> Throwing a recognition exception from a token stream is undefined.
> Who is supposed to catch it? you might not even use a parser?

main() or whatever is supposed to catch or not to catch it,
depending on circumstances which are known to lexer/parser user,
but not known to lexer/parser developer.

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

> 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 :)

> Ter

Guntis



More information about the antlr-interest mailing list