[antlr-interest] ANTLR Error Messages and getErrorMessage --- not being routed

Andreas Stefik stefika at gmail.com
Mon Feb 15 17:16:06 PST 2010


Paul,

Oh, hey, thanks!

I guess I didn't even think that the lexer might be sending off messages, as
I sort of assumed it all got routed behind the scenes to the parser. Now
that you say it, though, that makes sense. I tossed in some test methods
into the lexer and, low and behold, everything fires up as expected.

So, yaa, problem solved. Should be pretty easy from here to wire it all in.

Thanks again,

Stefik

On Mon, Feb 15, 2010 at 4:52 PM, Paul Bouché <paul.bouche at apertio.com>wrote:

> Hi Andreas,
>
> probably you are not catching the lexer errors. You also need to override
> one of the error reporting methods in the lexer, e.g.:
>
> @lexer::members {
>
>        public void emitErrorMessage(String msg) {
> // ...
>        }
>
>        public void recover(RecognitionException re) {
> // ...           reportError(re);
>        }
>
> }
>
> Some errors you will not see because the parser tries to recover from them
> and does not log them or you will only see it in certain methods, look at
> the call tree to find out which method is always called and hook in there.
> If I remember correctly emitErrorMessage() is not always called in the lexer
> / parser. You can switch of recovering all together if you throw an
> exception in the reover method. The lexer imo does something weird last time
> I looked into the source code: it eats up characters until it finds one for
> which it can continue properly (consumes, moves the read pointer forward),
> we did not need the behavior (only eat up till a certain char, e.g.' \n').
>
> BR,
> Paul
>
> Am 15.02.2010 21:35, schrieb Andreas Stefik:
>
>> Hello all,
>>
>> I have a grammar that I use for a custom virtual machine. In this machine,
>> we have our own custom syntax error reporting mechanism, which is tied
>> through the NetBeans platform using ANTLR. Recently, one of the members on
>> our development team noticed that "some" of the errors that ANTLR is
>> dumping
>> to the command line are not properly being routed through our syntax error
>> reporting mechanism.
>>
>>
>> The thing is, though, we aren't doing anything special with our reporting.
>> As a test to see which errors are being routed and which are not, we
>> modified our mechanism to do the simplest possible thing:
>>
>> @Override
>>     public String getErrorMessage(RecognitionException re, String[]
>> tokenNames) {
>>         return super.getErrorMessage(re, tokenNames);
>>     }
>>
>>     public String getTokenErrorDisplay(Token t) {
>>         return t.toString();
>>     }
>>
>> (this goes in @parser:members).
>>
>> Next, we generate the grammar and set breakpoints at the appropriate
>> points.
>> As expected, if we add in errors into our DSL, the breakpoints hit and the
>> errors are caught. However, if we add certain kinds of errors (e.g., an
>> extra semicolon at the end of a line when there shouldn't be one), ANTLR
>> seems to dump the error to the command line but not report it through
>> getErrorMessage (the breakpoint is not hit). For example, ANTLR might
>> output: line 15:24 no viable alternative at character ';' but not actually
>> route this through getErrorMessage, which means we don't detect it
>> programmatically.
>>
>> So, what exactly is going on here? Are there certain classifications of
>> errors that ANTLR dumps to the command line but does not route through
>> getErrorMessage? For these classes of errors, how can we force ANTLR to
>> send
>> us these as well, so that we can route them correctly through the rest of
>> our architecture?
>>
>> I tried using @rulecatch and a few other methods in BaseRecognizer (e.g.,
>> emit, reportError), according to the docs, but I can't seem to get ANTLR
>> to
>> route these particular errors through there either.
>>
>> Any thoughts?
>>
>> Stefik
>>
>> 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