[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