Mailing List Archive: Lucene: Java-Dev

[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one

Index | Next | Previous | View Threaded

jira at apache

Jun 18, 2009, 12:36 PM

Post #1 of 4 (389 views)
Permalink

[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one

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

Hoss Man commented on LUCENE-1646:
----------------------------------

As a general rule, code catching an execption and throwing a new exception with more details should (almost always) call initCause (unless the new Exception has a constructor that takes care of that part) to preserve all of the stack history.

Client code that wants to get at the root exception can do so using getCause()

In QueryParser...
{code}
} catch (ParseException tme) {
// rethrow to include the original query:
ParseException e = new ParseException("Cannot parse '" +query+ "': " + tme.getMessage());
e.initCause(tme);
throw e;
}
{code}

In Trejkaz's code, something like...
{code}
} catch (ParseException pexp) {
for (Throwable t = pexp; null != t; t = t.getCause()) {
if (t instanceof OurCustomException) {
takeActionOnCustomException((OurCustomException)t);
}
takeActionOnLuceneQueryParserException(exp)
}
}
{code}

> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

jira at apache

Jun 23, 2009, 12:42 PM

Post #2 of 4 (339 views)
Permalink

[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one [In reply to]

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

Michael McCandless commented on LUCENE-1646:
--------------------------------------------

I agree Hoss; I'll fix QueryParser to initCause when it catches & rethrows.

> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

jira at apache

Jul 4, 2009, 2:09 AM

Post #3 of 4 (324 views)
Permalink

[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one [In reply to]

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

Uwe Schindler commented on LUCENE-1646:
---------------------------------------

Mike: After LUCENE-1713, I recreated the QueryParser with javacc (because some changes in creation of RangeQueries), but the produced QueryParser.java did not contain your changes.

I copied your initCause() lines to QueryParser.jj and then it worked, I commit this together with LUCENE-1713.

> 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
> Fix For: 2.9
>
>
> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

jira at apache

Jul 4, 2009, 2:33 AM

Post #4 of 4 (307 views)
Permalink

[jira] Commented: (LUCENE-1646) QueryParser throws new exceptions even if custom parsing logic threw a better one [In reply to]

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

Michael McCandless commented on LUCENE-1646:
--------------------------------------------

Woops, thanks Uwe.

> 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
> Fix For: 2.9
>
>
> 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 [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads