[antlr-interest] Error reporting

Terence Parr parrt at cs.usfca.edu
Mon Jun 11 16:47:28 PDT 2007


On Jun 10, 2007, at 10:49 PM, Aleksi Kallio wrote:
> Hello all,

Hi Aleksi :)

> I've been checking out ANTLR and planning to use it in a multi- 
> threaded server scenario. I see that ErrorManager has been written  
> mostly with a single-threaded scenario in mind.

Well, you can have multiple threads emitting errors; we use our own  
"thread local" variables map:

	/** Each thread might need it's own error listener; e.g., a GUI with
	 *  multiple window frames holding multiple grammars.
	 */
	private static Map threadToListenerMap = new HashMap();

At least it's our intention to have it work this way. ;)

> There are a couple of issues I've stumbled into when trying to  
> adapt ANTLR into our case.
>
> 1) ErrorManager does support per-thread error listeners.
> However in our case we are pooling the threads we use to do all the  
> work.

oh!

> I believe the approach in ErrorManager will work, but does  
> introduce some ambiguity. Currently ErrorManager collects errors  
> into a single spot and redistibutes them. It would be nice if in  
> future you could also have independent listeners for each parse,  
> and could pass them from thread to thread without worries.

Hmm...well all methods such as error() ask for a separate listener:

	public static ANTLRErrorListener getErrorListener() {
		ANTLRErrorListener el =
			(ANTLRErrorListener)threadToListenerMap.get(Thread.currentThread());
		if ( el==null ) {
			return theDefaultErrorListener;
		}
		return el;
	}

Doesn't that work?

> 2) In ErrorManager there is this static constructor that's causing  
> a bit of a headache. Our locale is "FI" for which there are no  
> error messages available. So I get an error saying that we are  
> falling back to "US" error messages. Because this happens in the  
> static constructor, there is no way of preventing it by setting  
> ErrorManager's locale to "US" manually:
>
> static {
>   ...
>   // it is inefficient to set the default locale here if another
>   // piece of code is going to set the locale, but that would
>   // require that a user call an init() function or something.  I  
> prefer
>   // that this class be ready to go when loaded as I'm absentminded ;)
>   setLocale(Locale.getDefault());
>   ...
> }
>
> Is there a way to get around this? I would want the parser to be  
> silent and all error reporting to happen through our framework.

I think it should simply not make that error any more.  Would that  
work for you?  It would silently fail over to English default error  
msg template.

> Finally, thanks for the great software! I hope in future it also  
> stretches effortlessly into less conventional server side  
> scenarios... :)

Thanks for the feedback!
Ter



More information about the antlr-interest mailing list