[
https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711412#action_12711412
]
Trejkaz commented on LUCENE-1646:
---------------------------------
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.
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.
> QueryParser throws new exceptions even if custom parsing logic threw a better
> one
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-1646
> URL: https://issues.apache.org/jira/browse/LUCENE-1646
> 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: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
