[
https://issues.apache.org/jira/browse/SOLR-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774836#action_12774836
]
Hoss Man commented on SOLR-1546:
--------------------------------
It would be helpful if you could post the stacktraces for the exception(s) you
are seeing where there is no nested clause but you feel like there should be --
that way we'd have methods and line numbers of where the Exception originalted
in order to determine why the cause isn't being set properly.
the current bug description feels like a needle in a hay stack.
> When querying solrj the SolrServerException's cause is null
> -----------------------------------------------------------
>
> Key: SOLR-1546
> URL: https://issues.apache.org/jira/browse/SOLR-1546
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 1.4
> Environment: solrj
> Reporter: Jake Brownell
> Priority: Minor
>
> Our application processes queries like so:
> {code}
> try {
> final SolrServer server = getServer();
> final QueryResponse resp = server.query(query);
> return resp;
> } catch (final SolrServerException e) {
> /// bad things probably happened, invoke error processing and
> possibly switch to the backup
> }
> {code}
> Given SOLR-874 with dismax queries sometimes causing ParseException from
> Lucene, I'd like to be able to interrogate the cause chain of the
> SolrServerException. For example if I found ParseException in the chain, I
> could provide a specific error message and know that it's not necessary to
> switch to the backup server.
> As it is now, getCause is giving null. The undesirable fix right now is
> looking inside the toString/description for the "ParseException" phrase.
> Thanks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
