[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