The root of the ANTLR exception hierarchy.
To avoid English-only error messages and to generally make things as flexible
as possible, these exceptions are not created with strings, but rather the
information necessary to generate an error. Then the various reporting methods
in Parser and Lexer can be overridden to generate a localized error message. For
example, MismatchedToken exceptions are built with the expected token type. So,
don't expect getMessage() to return anything.
Note that as of Java 1.4, you can access the stack trace, which means that you
can compute the complete trace of rules from the start symbol. This gives you
considerable context information with which to generate useful error
ANTLR generates code that throws exceptions upon recognition error and also
generates code to catch these exceptions in each rule. If you want to quit upon
first error, you can turn off the automatic error handling mechanism using
rulecatch action, but you still need to override methods mismatch and
In general, the recognition exceptions can track where in a grammar a problem
occurred and/or what was the expected input. While the parser knows its state
(such as current input symbol and line info) that state can change before the
exception is reported so current token index is computed and stored at exception
time. From this info, you can perhaps print an entire line of input not just a
single token, for example. Better to just say the recognizer had a problem and
then let the parser figure out a fancy report.