[antlr-interest] C# Error Recovery

[Johannes Luber]

Gavin Lambert schrieb:
> At 10:12 17/04/2008, Loring Craymer wrote:
>> 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.
> 
> There's definitely no need to go adding extra fields -- they're already 
> there.  That was basically my point -- all C# exceptions already have a 
> settable message, and RecognitionException is no different (and it even 
> already includes constructors to set that message).  The only missing 
> piece of the puzzle is that GetErrorMessage completely ignores the 
> message set on the exception.
> 
> I would have thought that Java exceptions were the same?  (Googles.)  
> Yes, they are.
> 
> So for C#, changing the first line of BaseRecogniser.GetErrorMessage from:
>   string msg = null;
> to:
>   string msg = e.Message;
> is all that's required.  Similarly for Java's 
> BaseRecogniser.getErrorMessage:
>   String msg = e.getMessage();
> (or even getLocalizedMessage(), if you prefer.)

Unless Ter objects against this change, I will include it. I prefer the 
same behaviour over improved functionality, as Java is the role model 
for all targets.

> It would most likely be similarly minor for any other target language 
> that supports exceptions, and only slightly more complex for others.  
> (C++ actually falls halfway between the two.  The standard doesn't 
> actually mandate that std::exception have a constructor which can take a 
> string and store it, so some implementations do and some don't.  But 
> there isn't a C++ target at the moment anyway, so the point is moot.)
> 
> But at the end of the day, having some way to raise user-specified 
> errors which are treated similarly to "standard" errors (as far as error 
> recovery and reporting go) seems like an essential thing to have.
> 
> What would be even cooler would be a way to link a 
> target-code-block-that-returns-a-string to a validating predicate, 
> basically cutting out the middle-man, since it seems to me like 
> validating predicates are the most likely source of user-specified 
> errors.  But that's a separate issue; being able to catch the 
> FailedPredicateException and rethrow it as a custom one is sufficient.

I'm in favor of this, as this localizes more grammar issues into one file.

>> 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.
> 
> The second suggestion was simply a logical follow-through from the first 
> -- if you're using the text in the exceptions, and that text can 
> usefully be constructed by the exception itself (as with 
> FailedPredicateException), then why not do it?  Sure, still have the 
> central method which can be used for localisation or whatever other 
> overriding you want (Ter's right, it's a good idea), but why not make 
> the exception classes self sufficient?
> 
> I'm not really sure what you're saying about the "token error display" 
> though.  I never suggested removing that; I was suggesting that enough 
> information be given to the exception constructors so that they can 
> generate it themselves.
> 
> But, whatever.  The second idea isn't really all that important, it's 
> just a stylistic thing.  The first, however, I think is vital.

Not entirely stylistic. After all, Ter used procedural programming in a 
place, which could benefit from polymorphism. Having a catch-all clause 
doesn't very well with me. Using the compiler to choose the right text 
message is easier and one might not have to override getErrorMessage().

Johannes