lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one
Date Thu, 21 May 2009 11:25:45 GMT


Michael McCandless commented on LUCENE-1646:

bq. I guess that's true if you look at exceptions as a logging mechanism, but in our case
it's a parsing exception for text coming from the user. Because of this, our use case is for
the user to get a useful error message, and it's not useful at all if we just tell them their
entire query was bad. Thus we have inserted improvements (in our subclass) to make it complain
only about the fragment of the query which is actually a problem, so they know which part
to fix.

I agree, in general an app ought to be catching this ParseException
and messaging something much more succinct/digestible to the end

When QueryParser throws ParseException, it does attempt to explain
what went wrong in many cases.  It sounds like you've modified it
further to do a better job?  Is this something you could donate back?

I agree we should make it easier to customize the ParseException, but
I think by default having the exception message include the full query
is useful for those apps that simply log the exception.  This way we
can have our cake and eat it too...

bq. Related, but is there any way it could at least be reduced to the portion of the query
which caused the problem? In a way it would be nice if ParseException had methods to get out
the problematic fragment (my subclass has it...) I'm guessing this is much easier for exceptions
relating to values inside fields which otherwise parsed correctly, but a lot harder to do
for exceptions from the parser proper.

It seems like it already makes some effort here?  Eg it has
attrs like currentToken, expectedTokenSequences,
etc., recorded when the exception is thrown.  And getMessage()
pulls from these attrs to build up the message?  Can you post a patch
with your improvements here?

> QueryParser throws new exceptions even if custom parsing logic threw a better one
> ---------------------------------------------------------------------------------
>                 Key: LUCENE-1646
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 2.4.1
>            Reporter: Trejkaz
> We have subclassed QueryParser and have various custom fields.  When these fields contain
invalid values, we throw a subclass of ParseException which has a more useful message (and
also a localised message.)
> Problem is, Lucene's QueryParser is doing this:
> {code}
>     catch (ParseException tme) {
>         // rethrow to include the original query:
>         throw new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
>     }
> {code}
> Thus, our nice and useful ParseException is thrown away, replaced by one with no information
about what's actually wrong with the query (it does append getMessage() but that isn't localised.
 And it also throws away the underlying cause for the exception.)
> I am about to patch our copy to simply remove these four lines; the caller knows what
the query string was (they have to have a copy of it because they are passing it in!) so having
it in the error message itself is not useful.  Furthermore, when the query string is very
big, what the user wants to know is not that the whole query was bad, but which part of it
was bad.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message