[antlr-interest] Correct way to handle custom errors?

Stephen McGruer stephen.mcgruer at gmail.com
Mon Feb 7 11:46:46 PST 2011


Quick update on this. I managed to grab the current line from the
inputstream by doing the following:

CharStream cs = (CharStream) e.input;
cs.mark();
cs.seek((cs.index() - 1));
System.out.println(cs.substring(0, cs.index() - 1);
cs.rewind();

And this doesnt seem to interfere with later scanning (or parsing), but...
is this okay? It seems awfully dodgy.

Stephen

On 7 February 2011 17:48, Stephen McGruer <stephen.mcgruer at gmail.com> wrote:

> Jim,
>
> Thanks for the suggestion - although I don't quite want the level of detail
> you guys go into (and I don't quite understand all of it, possibly because I
> don't know the JavaFX syntax!) the source code was very useful and I think
> I've now got enough to put in some decent error messages.
>
> There are two things I'm still having trouble with that I think are related
> to this question strongly enough to not warrant a new thread. The first is
> printing out the line that the error occurred on. I wanted to try out
> mimicking the sort of print out that javac does when it encounters an error,
> but I can't work out how to get access to the text of the line that is
> having the problem. I read here -
> http://www.antlr.org/wiki/pages/viewpage.action?pageId=1769 - that if you
> are using the CommonTokenStream you should have access to a "token" with the
> information, but in my getErrorMessage override that simply returns null for
> most of the errors I've tried (currently MisMatchedToken exceptions):
>
> public String getErrorMessage(RecognitionException e, String[] tokenNames)
> {
>     // Prints out true!
>     System.out.println(e.token == null);
> }
>
> I then read that you can use the inputstream attached to the
> RecognitionException instead (can't quite remember where... the official
> docs?), but can't figure out how to do this. Currently I have tried casting
> it from an IntStream to a CharStream (I think it will always be a CharStream
> for me... maybe XD) and played with the various methods available, but none
> of them seem to offer a way to just print out the current line. The most
> promising looks like substring(start, stop), but I cannot find a way to get
> the length of the line to give as the "stop" parameter! I also assume that
> if I do this method I should mark the stream before I begin, and rewind it
> once I'm done?
>
> Alternatively, if there's a "better" way to do this when overriding the
> getErrorMessage method please tell me.
>
> The second problem I'm having is with is stopping the parser from running
> if the lexer has spat out any errors. As far as I can tell, it's very
> possible and easy to stop the lexer after a single error message is thrown,
> but I cannot find anywhere that shows how to let the lexer continue but not
> let the parser run. Since all error messages are only thrown once you call
> something like "program_return parserResult = parser.program();" (i.e. the
> lexer has no errors until after this line), then I can't stop it parsing the
> syntactically invalid file and spitting out more (useless, imo) error
> messages! Is there a 'correct' or even just any way to achieve this?
>
> Thanks,
> Stephen
>
>
> On 5 February 2011 16:28, Jim Idle <jimi at temporal-wave.com> wrote:
>
>> If you download the source code to the Java FX compiler you will have a
>> complete example to work from, assuming a Java target. Start by creating a
>> superclass for the parser and overriding various error reporting points.
>> The JavaFX compiler will show you how to do that.
>>
>> Jim
>>
>> > -----Original Message-----
>> > From: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
>> > bounces at antlr.org] On Behalf Of Stephen McGruer
>> > Sent: Friday, February 04, 2011 4:14 PM
>> > To: antlr-interest at antlr.org
>> > Subject: [antlr-interest] Correct way to handle custom errors?
>> >
>> > I was wondering what the "correct" way to handle custom errors in ANTLR
>> > 3 was. I'm implementing a parser/lexer for a small subset of C, and
>> > want to give better error messages than the general mismatched tokens
>> > error.
>> >
>> >  From this post -
>> > http://www.antlr.org/wiki/display/ANTLR3/Error+reporting+and+recovery I
>> > implemented my own error reporting class which grabs the recognition
>> > exception from the Parser. However, I'm then unsure about the best
>> > approach is to start recognising errors - from things as basic as
>> > replacing the name of my variable name rule (ID) with a more user-
>> > friendly term such as "identifier", to more complex things such as
>> > giving nice error messages when the user attempts to set a variable to
>> > a value that isn't an integer or character (the only two allowable
>> > types in my subset). The recognition exception doesn't seem to be too
>> > useful - getMessage() seems to return null.
>> > I assume that the getErrorHeader and getErrorMessage methods do
>> > something different to get information. The only way I can think of
>> > checking for errors at the moment is manually scraping the strings
>> > returned by these methods, which seems... clumsy.
>> >
>> > So, is there a sort of "normal" or "usual" method to approaching
>> > parser/lexer error message handling when doing programming language
>> > parsing?
>> >
>> > I hope the above contained enough information, and made sense.
>> >
>> > Thanks,
>> > Stephen
>> >
>> > List: http://www.antlr.org/mailman/listinfo/antlr-interest
>> > Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-
>> > email-address
>>
>> 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