[antlr-interest] C# Error Recovery

[Gavin Lambert]

[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.]

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.)

>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.)

>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.

>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.


-- 
Gavin Lambert, Mirality Systems
<http://www.mirality.co.nz/>
<http://lambert.geek.nz/>
----
Anyone who goes to a psychiatrist ought to have their head 
examined.

Few women admit their age.  Few men act theirs.