Обработка ошибок в ANTLR4

при использовании DefaultErrorStrategy или BailErrorStrategy на ParserRuleContext.exception поле устанавливается для любого узла дерева синтаксического анализа в результирующем дереве синтаксического анализа, где произошла ошибка. Документация для этого поля гласит (для людей, которые не хотят нажимать дополнительную ссылку):

исключение, которое заставило это правило вернуться. Если правило успешно завершено, это null.

Edit: если вы используйте DefaultErrorStrategy, исключение контекста разбора не будет распространяться на весь путь до вызывающего кода, поэтому вы сможете изучить exception поле напрямую. Если вы используете BailErrorStrategy на ParseCancellationException брошенный им будет включать в себя RecognitionException если вы называете getCause().

if (pce.getCause() instanceof RecognitionException) {
    RecognitionException re = (RecognitionException)pce.getCause();
    ParserRuleContext context = (ParserRuleContext)re.getCtx();
}

Edit 2: основываясь на вашем другом ответе, похоже, что вы на самом деле не хотите исключения, но то, что вы хотите, - это другой способ сообщить об ошибках. В этом случае, вы будете больше заинтересованы в ANTLRErrorListener интерфейс. Вы хотите позвонить parser.removeErrorListeners() чтобы удалить прослушиватель по умолчанию, который записывает на консоль, а затем вызвать parser.addErrorListener(listener) для вашего собственного специального слушателя. Я часто использую следующий слушатель в качестве отправной точки, так как он содержит имя исходного файла с сообщениями.

public class DescriptiveErrorListener extends BaseErrorListener {
    public static DescriptiveErrorListener INSTANCE = new DescriptiveErrorListener();

    @Override
    public void syntaxError(Recognizer<?, ?> recognizer, Object offendingSymbol,
                            int line, int charPositionInLine,
                            String msg, RecognitionException e)
    {
        if (!REPORT_SYNTAX_ERRORS) {
            return;
        }

        String sourceName = recognizer.getInputStream().getSourceName();
        if (!sourceName.isEmpty()) {
            sourceName = String.format("%s:%d:%d: ", sourceName, line, charPositionInLine);
        }

        System.err.println(sourceName+"line "+line+":"+charPositionInLine+" "+msg);
    }
}

С этим классом доступны, вы можете использовать следующее, чтобы использовать его.

lexer.removeErrorListeners();
lexer.addErrorListener(DescriptiveErrorListener.INSTANCE);
parser.removeErrorListeners();
parser.addErrorListener(DescriptiveErrorListener.INSTANCE);

A много более сложный пример прослушивателя ошибок, который я использую для выявления двусмысленностей, которые делают грамматику не SLL, - это SummarizingDiagnosticErrorListener класс TestPerformance.

то, что я придумал до сих пор, основано на расширении DefaultErrorStrategy и переопределить это reportXXX методы (хотя вполне возможно, я делаю вещи более сложными, чем это необходимо):

public class ExceptionErrorStrategy extends DefaultErrorStrategy {

    @Override
    public void recover(Parser recognizer, RecognitionException e) {
        throw e;
    }

    @Override
    public void reportInputMismatch(Parser recognizer, InputMismatchException e) throws RecognitionException {
        String msg = "mismatched input " + getTokenErrorDisplay(e.getOffendingToken());
        msg += " expecting one of "+e.getExpectedTokens().toString(recognizer.getTokenNames());
        RecognitionException ex = new RecognitionException(msg, recognizer, recognizer.getInputStream(), recognizer.getContext());
        ex.initCause(e);
        throw ex;
    }

    @Override
    public void reportMissingToken(Parser recognizer) {
        beginErrorCondition(recognizer);
        Token t = recognizer.getCurrentToken();
        IntervalSet expecting = getExpectedTokens(recognizer);
        String msg = "missing "+expecting.toString(recognizer.getTokenNames()) + " at " + getTokenErrorDisplay(t);
        throw new RecognitionException(msg, recognizer, recognizer.getInputStream(), recognizer.getContext());
    }
}

это вызывает исключения с полезными сообщениями, и линия и положение проблемы могут быть получены из любого offending маркер, или если это не установлено, от current маркер с помощью ((Parser) re.getRecognizer()).getCurrentToken() на RecognitionException.

Я довольно доволен тем, как это работает, хотя имея шесть reportX методы для переопределения заставляет меня думать, что есть лучший способ.