lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trejkaz (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one
Date Thu, 21 May 2009 22:49:45 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711850#action_12711850
] 

Trejkaz commented on LUCENE-1646:
---------------------------------

Our improvements are (so far) specific to our subclass of QueryParser, in that we use it when
getFieldQuery() gets a value which doesn't make sense for the given field.

So in a sense, in our case the query was parsed successfully by the parser, but the input
was invalid within one of the fields.  As such our custom ParseException subclass has the
field name and field value, but it isn't useful to the Lucene project as-is, as the only things
throwing it are called from our subclass. :-(


> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message