[antlr-interest] C# Error Recovery

[Gavin Lambert]

At 11:26 18/04/2008, Loring Craymer wrote:
>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.

Yes, that's basically what I was suggesting; pass enough 
information to the exception constructor so that it can construct 
the error message it needs to, whether directly as parameters or 
indirectly via passing the recogniser itself or an interface to 
get error information.

Also, wherever possible this information should be cached 
(separately) in the exception instance as well, so that the 
exception message can be rejiggered later without having to refer 
to anything else (except a string lookup 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.

Well, you should never try to replace sub-strings when doing 
localisation anyway.  At minimum a whole sentence, but preferably 
an entire "unit" -- in this case, the whole error.

This is trivial in C#, you just use a different format string; eg. 
your code looks like this:
   string error = String.Format(Resources.SomeError, foo, bar, 
baz);
(where foo, bar, and baz are bits of interesting data that you 
might want to include in the error message)

The English resources might be:
   Error 14: "{0}" is not a valid value for "{1}" in "{2}".
And the French resources might be:
   Erreur 14: Dans "{2}", "{0}" est une valeur incorrecte pour 
"{1}".

The important point being that inserted components should be able 
to be reordered, duplicated, and even left out entirely, as 
appropriate.

(Also, I apologise to any French speakers if I've butchered the 
language; I don't actually speak French so I just used an online 
translator.)

I imagine StringTemplate can be used to do this sort of thing as 
well (I've never really looked at it too closely, so I don't 
know).  Still, even without StringTemplate, if there isn't 
anything built in to a given language to do this, it's pretty easy 
to write one.  (I've done it before.)

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

True.