[antlr-interest] case sensitivity for ANTLR v3 lexers
Terence Parr
parrt at cs.usfca.edu
Tue May 16 17:57:01 PDT 2006
On May 16, 2006, at 5:39 PM, Don Caton wrote:
> Ter:
>
>>> I understand that you're using ST to generate code in 3.0,
>> but how is
>>> that relevant at runtime? Will ST be required at runtime as well?
>>
>> Oh, sorry...i meant ANTLR v3 errors not parse errors. Just
>> override reportError(Exception e) and you're groovy!
>
> That doesn't work, at least not in 2.x. By the time reportError() is
> called, the exception object (and its textual message) have already
> been
> created, using strings that are hard-coded in the various exception
> classes.
Sample v3 output:
catch (RecognitionException re) {
reportError(re);
recover(input,re);
}
note not a single literal in the output...almost as if i'd learned my
lesson! Yep, you shall revel in the joy that is v3.
> Take a look at MismatchedCharExpression:getMessage(), for example.
> Even if
> I subclassed this object, there's no way to get the generated code
> to use
> it. The only way to fix this is to modify the code every time a
> new version
> is released.
If you override reportError you are golden...no strings...
/** Report a recognition problem. Java is not polymorphic on the
* argument types so you have to check the type of exception yourself.
* That's not very clean but it's better than generating a bunch of
* catch clauses in each rule and makes it easy to extend with
* more exceptions w/o breaking old code.
*
* This method sets errorRecovery to indicate the parser is recovering
* not parsing. Once in recovery mode, no errors are generated.
* To get out of recovery mode, the parser must successfully match
* a token (after a resync). So it will go:
*
* 1. error occurs
* 2. enter recovery mode, report error
* 3. consume until token found in resynch set
* 4. try to resume parsing
* 5. next match() will reset errorRecovery mode
*/
public void reportError(RecognitionException e) {
// if we've already reported an error and have not matched a token
// yet successfully, don't report any errors.
if ( errorRecovery ) {
//System.err.print("[SPURIOUS] ");
return;
}
errorRecovery = true;
displayRecognitionError(this.getClass().getName(),
this.getTokenNames(),
e);
}
>>> All I'm really looking for is an overridable "getErrorString()"
>>> method, or
>>> something like that, so I can supply an appropriate error message
>>> depending on the end user's locale. The default
>> implementation could
>>> use the English messages, please just allow some clean way of
>>> overriding them at runtime.
>>
>> You have, sir! See the runtime stuff...doesn't use ST at all.
>
> I thought the C++ runtime stuff wasn't written yet? Or am I not
> looking in
> the right place?
Well, I'm assuming Ric follows my lead on this...
Ter
More information about the antlr-interest
mailing list