[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:07:29 AM
Subject: Re: [antlr-interest] C# Error Recovery

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.

The Java RecognitionException does not have a msg field--most of its children do.

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.

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.

But, whatever.  The second idea isn't really all that important, 
it's just a stylistic thing.  The first, however, I think is 
vital.

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

--Loring






      ____________________________________________________________________________________
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/72a064f8/attachment-0001.html