[antlr-interest] parser runtime error listeners

Gordon Tyler Gordon.Tyler at quest.com
Wed Apr 21 07:22:55 PDT 2010


The parser itself could register a listener, which calls reportError.

-----Original Message-----
From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-bounces at antlr.org] On Behalf Of Terence Parr
Sent: April 20, 2010 5:45 PM
To: ANTLR interest
Subject: [antlr-interest] parser runtime error listeners

Hiya. GeraldHas brought up an excellent point about our runtime. Currently, parsing errors get reported through method reportError. To do something different, you have to override that method. Gerald is suggesting that we move to an error listener mechanism so that multiple listeners can attach to a running parser and receive error events (kind of like what we do for debugging events).

I'm all for this idea, but what about backward compatibility? a lot of people have overridden reportError in their parsers or tree parsers (like me) and we want that to continue to work. How do we integrate this with a listener mechanism? Also, Gerald points out that even if someone overrides that method, his tool and other tools for integration with eclipse need to get those errors regardless of whether someone has overridden reportError. Otherwise, the ANTLR IDE couldn't get  syntax error messages when it ran. He suggested

> Preferably, the listener interface would be above anything that the end user could override.  Stuff that now calls reportError should instead call some private "reportError_intern", which fires the event listeners and then calls the public/overrideable "reportError".

any comments on the approach or what we want?

The minute I get v4 running in v3, I want to turn around and have v4 generate its own parsers. Backward compatibility will also be important for me.

Ter

List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address


More information about the antlr-interest mailing list