[antlr-interest] Fwd: C# Error Recovery

[Adam Connelly]

Sorry, I keep pressing reply instead of reply to all.

---------- Forwarded message ----------
From: Adam Connelly <adam.rpconnelly at googlemail.com>
Date: 17 Apr 2008 18:23
Subject: Re: [antlr-interest] C# Error Recovery
To: Johannes Luber <jaluber at gmx.de>

This is kind of related to what I was talking about in another thread
("Better Error Handling in ANRTL" or something like that).  Why not remove
the actual error reporting from the recogniser completely?  That way you'd
still have all the reporting (i.e. what to do with errors and not what to do
when one occurs which is slightly different) in the same place, and it would
also be easier (IMO anyway) to alter the way that errors are reported.

You could also then change the error reporter used by a parser at runtime.
But anyhow, I won't re-write the suggestion here.

Adam

On 17/04/2008, Johannes Luber <jaluber at gmx.de> wrote:
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080417/b07e0196/attachment.html