[antlr-interest] C# Error Recovery

[Loring Craymer]

Most of the cases call "getTokenErrorDisplay() which cannot be pushed into the exceptions, and none of the error messages are localized (minimalist assumption:  StringTemplate is not available for the target language).  I suggest adding an "msg" field to RecognitionException so that Gavin's first suggestion can be implemented.  I would argue against implementing Gavin's second suggestion at this time:  the token error display adds clarity for the user (yeah, you can look at line 13, figure out that "message" is in column 2, and then try to understand what just happened; but it is easier to look for "message" on line 13), and the current approach does allow the user to override getErrorMessage() to support localization via StringTemplate.

--Loring


----- Original Message ----
From: Johannes Luber <jaluber at gmx.de>
To: Gavin Lambert <antlr at mirality.co.nz>
Cc: antlr-interest at antlr.org
Sent: Wednesday, April 16, 2008 1:55:10 PM
Subject: Re: [antlr-interest] C# Error Recovery

Gavin Lambert schrieb:
> I have a rule like this in my grammar (C# target, latest interim build):
> 
> tag[String name]
>     :    WS? t=TAG { $t.text.Equals("<" + $name + ">") }? NL
>     ;
> catch [FailedPredicateException ex] { throw new 
> RecognitionException("Expected <" + $name + "> but found " + $t.text, 
> ex, Input); }
> 
> The intent should be clear -- I want to validate that I'm receiving the 
> tag I'm expecting to get at that point in the input, but I want to give 
> it a custom error message.
> 
> I want all the normal ANTLR backtracking and recovery mechanisms to take 
> effect, which basically seems to mean that I need to be throwing a 
> RecognitionException or derived class thereof.
> 
> The problem lies in BaseRecognizer.GetErrorMessage, which completely 
> ignores the Message of the incoming exception and uses a series of 
> type-specific tests to construct a new message; leaving it blank if a 
> base RecognitionException is thrown.  I can work around this by deriving 
> a new exception from RecognitionException and overriding GetErrorMessage 
> to deal with that appropriately, but I shouldn't need to.
> 
> Proposed fixes:
> 
> 1. At minimum, the first line of GetErrorMessage should be changed to 
> assign "e.Message" as the default message, not null.
> 
> 2. Preferably, *all* the type specific code in GetErrorMessage should be 
> removed, and the exception Message should be set to the equivalent when 
> the exception is thrown in the first place (in their constructors).  It 
> just seems silly to try to "fix it up" after the fact.
> 
I'm not opposed against a fix, but the last paragraph isn't quite clear 
to me. Equivalent of what? Furthermore, Ter, why is that code, as it is? 
After all, it is like this in the Java target, too.

Johannes







      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080416/37eed68f/attachment.html