[antlr-interest] How to feedback to users the string expected on MismatchedTokenException

Silvester Pozarnik silvester.pozarnik at tracetracker.com
Tue Jun 19 03:28:57 PDT 2007


...
> >
> > NoViableAltException nvae =
> > new NoViableAltException("1:1: Tokens : ( SELECT | SEMI | WS);",
> > 1, 0, input);
> >
> > where the 'SELECT' is used. Such an error reporting may mean
something
> > to the guy that wrote the parser & lexer definition, but is
completely
> > useless for those who provide the input according to the defined
> > vocabulary.
>
>
> Benjamin Niemann wrote:
> 
> NoViableAltExceptions are especially tricky. In simple cases you could
> just
> report a set of expected tokens or short token sequences for each
> alternative. But once fancy stuff like LL(*) or predicates are
involved,
> things get complicated. I don't think there's a general way for ANTLR
to
> construct better error messages yet. What would be needed is a
> 'paraphrase'
> option as in V2, preferably for rules and subrules. decisionNumber and
> stateNumber from the exception ('1' and '0' above) may than somehow be
> used
> to fetch the appropriate paraphrases.

Fair enough and completely understandable. The problem is still that in
case sensitive grammars you should be able to report the expected token
with a string value where the characters are in the same case as
expected and _not_ in the upper case. In java, which is a case sensitive
language, you should expect the parser to report something as "Expecting
'implements' or 'extends' at 0:28 ..." and not "Expecting IMPLEMENTS or
EXTENDS at 0:28 ..." in case of syntax error as this:

	public class MyTokenStream IMPLEMENTS TokenStream {...

The same goes for NoViableAltException where the tokens are reported in
upper case regardless of the logic of predicting the alternatives.

The problem is that the tokens string value is lost in the grammar
processing.

BR
Silvester Pozarnik




More information about the antlr-interest mailing list