[ 
https://issues.apache.org/jira/browse/SOLR-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064145#comment-16064145
 ] 

Jason Gerlowski commented on SOLR-10956:
----------------------------------------

Currently, most {{SolrClient}} Javadocs say the following about potential error 
cases:
{code}
   * @throws IOException         if there is a communication error with the 
server
   * @throws SolrServerException if there is an error on the server
{code}

There are a few issues with this:
1. It makes no mention of RemoteSolrException at all.
2. SolrServerException is documented as having the role that 
RemoteSolrException has in practice.
3. IOException is documented as having the role that SolrServerException has in 
practice.  (Some IOExceptions do leak out of SolrClient classes, but they're 
very often wrapped in a SolrServerException)

To take a stab at fixing these issues, I would suggest documentation like:
{code}
    * @throws RemoteSolrException errors encountered executing the request on 
the remote server, such as invalid request rejection or internal server errors. 
 Check #code() for hints at retriability.
   * @throws SolrServerException errors encountered attempting to communicate 
with Solr such as connection, timeout, or parsing errors.
   * @throws IOException unexpected communication errors.
{code}

Anyone have any thoughts?

> Document SolrClient use of RemoteSolrException
> ----------------------------------------------
>
>                 Key: SOLR-10956
>                 URL: https://issues.apache.org/jira/browse/SOLR-10956
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SolrJ
>    Affects Versions: master (7.0)
>            Reporter: Jason Gerlowski
>            Priority: Minor
>
> Currently, {{SolrClient}}s Javadocs specify that it throws IOException, and 
> SolrServerException.  However, these aren't the only exceptions that can 
> trickle out of these classes.
> {{RemoteSolrException}} for example, is often thrown by {{HttpSolrClient}} on 
> various error cases:
> {code}
> [~/c/lucene-solr] $ grep -rI "throw new RemoteSolrException" . | grep 
> SolrClient.java
> ./solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java:  
>           throw new RemoteSolrException(baseUrl, httpStatus, "non ok status: 
> " + httpStatus
> ./solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java:  
>           throw new RemoteSolrException(baseUrl, httpStatus, "Could not parse 
> response with encoding " + encoding, e);
> ./solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java:  
>         throw new RemoteSolrException(baseUrl, httpStatus, msg, null);
> ./solr/solrj/src/java/org/apache/solr/client/solrj/impl/HttpSolrClient.java:  
>       throw new RemoteSolrException(baseUrl, httpStatus, e.getMessage(), e);
> {code}
> (LBHttpSolrClient, and CloudSolrClient also see these exception, since they 
> wrap HttpSolrClient internally)
> We should either restrict the exceptions we throw in our clients, or better 
> document the full range of possible exceptions/error-cases so that users can 
> better handle things themselves.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to