[antlr-interest] C# Error Recovery

[Loring Craymer]

----- Original Message ----
> From: Gavin Lambert <antlr at mirality.co.nz>
> To: Loring Craymer <lgcraymer at yahoo.com>; Johannes Luber <jaluber at gmx.de>
> Cc: antlr-interest at antlr.org
> Sent: Thursday, April 17, 2008 2:34:47 PM
> Subject: Re: [antlr-interest] C# Error Recovery
> 
> [BTW, the quoting was messed up on your last post.  If I hadn't 
> written it myself it would have been hard to tell which were the 
> quotes and which were your responses.]

That's yahoo mail--it defaults to html format.

> 
> At 08:49 18/04/2008, Loring Craymer wrote:
> >The Java RecognitionException does not have a msg field--most of 
> >its children do.
> 
> They don't need separate fields; Throwable has the field.  That's 
> my point.  They just need to pass it along to their base 
> class.  (Which the C# runtime already does.)

Yeah, you could propagate the message back to the Throwable constructor.

> 
> >You can't do that, though--the token types and display formats 
> >(since ANTLR3 defaults to Objects for tokens) are defined at the 
> >application level, while the exception classes are library items 
> >and know nothing about the application.  The application's 
> >recognizer(s), though, are subclasses of BaseRecognizer and can 
> >know about application features.
> 
> That doesn't follow.  The recogniser is what is throwing the 
> exception in the first place.  It should be trivial for it to 
> either pass in the token names directly (in addition to the token 
> ids, which it already does), or to pass in some interface that the 
> exception constructor can call to fetch the token names as 
> needed.  (I prefer the former, but the latter is more extensible 
> and will lead to less API fluctuation.)

The Java version passes the input stream when creating exceptions, not token information.  I suppose that the critical information could be passed in an object via a "getErrorInfo()" method from BaseRecognizer.  Of course, you would probably need a "getSetDisplay()", a "getRangeDisplay()" and maybe a few other new methods to add to BaseRecognizer.

> 
> >Actually, I thought that it was good that you raised the point--I 
> >just responded that it was not a good solution  at this time, 
> >since localization is an important factor for (commercial) apps.
> 
> I don't see that this hinders localisation much, especially since 
> the GetErrorMessage overridable would still be there, permitting 
> central overriding of all the messages.
> 
> I guess it does make finding the specific text that needs 
> translating a little harder, but that's easily mitigated by making 
> the exceptions use a string lookup table rather than hard-coding 
> string constants.  Then the standard strings could be localised 
> simply by updating that table.

ST is much cleaner for that purpose, just not universal.  Hard coding a set of substrings to be matched and replaced would be error-prone.

> 
> >The ANTLR 3 exception management (tool, not runtime) is pretty 
> >decent, but the runtime support is still in need of work, largely 
> >because the current implementation was designed for 
> >transportability across target language implementations and Ter 
> >could not assume the existence of StringTemplate support when he 
> >wrote it.
> 
> Fair enough.  That's a good assumption to hold, even now.  I still 
> don't think that invalidates my point, though.
> 

I never said that it did, just that pushing string construction into the exception classes affects localization and should not be done as a quick fix.  Ter's response of adding a bug report was the right response from my perspective--usability issues often require deliberation, and this is certainly a case where there is likely to be a better solution.

--Loring

> -- 
> Gavin Lambert, Mirality Systems
> 
> 
> ----
> Anyone who goes to a psychiatrist ought to have their head 
> examined.
> 
> Few women admit their age.  Few men act theirs.
> 
> 




      ____________________________________________________________________________________
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/20080417/ba8dbd74/attachment.html