From 2a34d00d09f18096875fa31efc5c54f41767a77a Mon Sep 17 00:00:00 2001 From: parrt Date: Sun, 2 Oct 2011 13:18:10 -0800 Subject: [PATCH] tweak [git-p4: depot-paths = "//depot/code/antlr4/main/": change = 9094] --- .../org/antlr/v4/runtime/BaseRecognizer.java | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/runtime/Java/src/org/antlr/v4/runtime/BaseRecognizer.java b/runtime/Java/src/org/antlr/v4/runtime/BaseRecognizer.java index 8330e98d5..83a3144cd 100644 --- a/runtime/Java/src/org/antlr/v4/runtime/BaseRecognizer.java +++ b/runtime/Java/src/org/antlr/v4/runtime/BaseRecognizer.java @@ -318,24 +318,6 @@ public abstract class BaseRecognizer extends Recognizer { if ( traceATNStates ) _ctx.trace(atnState); } - /* In v3, programmers altered error messages by overriding - displayRecognitionError() and possibly getTokenErrorDisplay(). - They overrode emitErrorMessage(String) to change where the output goes. - - Now, in v4, we're going to use a listener mechanism. This makes it - easier for language applications to have parsers notify them - upon error without having to override the parsers. If you don't specify - a listener, ANTLR calls the v3 legacy displayRecognitionError() - method. All that does is format a message and call emitErrorMessage(). - Otherwise, your listener will receive RecognitionException - exceptions and you can do what ever you want with them including - reproducing the same behavior by calling the legacy methods. - (In v4, RecognitionException includes the recognizer object). - - Grammar tools can have a listeners without having to worry about - messing up the programmers' error handling. - */ - public void reportConflict(int startIndex, int stopIndex, Set alts, OrderedHashSet configs) {}