[antlr-interest] C# Error Recovery

Gavin Lambert antlr at mirality.co.nz
Wed Apr 16 14:20:48 PDT 2008


At 08:55 17/04/2008, Johannes Luber wrote:
 >I'm not opposed against a fix, but the last paragraph isn't
 >quite clear to me. Equivalent of what?

Equivalent of what the current version is doing in 
GetErrorMessage.

For example, currently the FailedPredicateException constructors 
don't set the Message at all (though the base class will then 
implicitly set it to "An exception of type 
'FailedPredicateException' was thrown.").

In BaseRecognizer.GetErrorMessage, the returned error message for 
a FailedPredicateException is "rule "+ruleName+" failed predicate: 
{"+predicateText+"}?".

I can see absolutely no reason why that isn't simply done in the 
exception's constructor, simply returning the Message in 
GetErrorMessage.  (The function itself should probably still 
exist, in case people want to customise the message for eg. 
translation.)

 >Furthermore, Ter, why is that code, as it is?  After all, it
 >is like this in the Java target, too.

For some of the other exceptions it does seem to do a bit more 
work, such as looking things up in tokenNames and calling 
GetTokenErrorDisplay or GetCharErrorDisplay (the first of which 
requires access to the recogniser; the second two don't really 
unless the method is overridden).  But that information could 
simply be passed to the exception constructors as well, since 
they're always called within the scope of a recogniser.


(And while on the subject: why does TreeParser.GetErrorMessage 
open with "if (this is TreeParser)"?  This is an impossible 
condition to fail, given the location of the method.  In fact, the 
compiler realises this and actually converts it to "if (this != 
null)", which is still equally impossible to fail given that it's 
a virtual method.)



More information about the antlr-interest mailing list