[antlr-interest] C# Error Recovery

[Gavin Lambert]

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

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