Used for remote debugger deserialization
If you are parsing a tree node stream, you will encounter som imaginary nodes w/o line/col info. We now search backwards looking for most recent token with line/col info, but notify getErrorHeader() that info is approximate.
The 0-based index into the line where the error occurred.
What is index of token/char were we looking at when the error occurred?
What input stream did the error occur in?
Track the line (1-based) at which the error occurred in case this is generated from a lexer. We need to track this since the unexpected char doesn't carry the line info.
If this is a tree parser exception, node is set to the node with the problem.
The current Token when an error occurred. Since not all streams can retrieve the ith Token, we have to track the Token object. For parsers. Even when it's a tree parser, token might be set.
Return the token type or char of the unexpected input element
Generated using TypeDoc
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 messages.
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 recoverFromMismatchSet.
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.