[
https://issues.apache.org/jira/browse/SOLR-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14334881#comment-14334881
]
Shawn Heisey commented on SOLR-7151:
------------------------------------
bq. I'm not sure if this should go into 5.x as well as trunk, as it's a
backwards-breaking change. I'm leaning towards yes, as it's a sufficiently
useful API change that it's worth the break, but I'm not going to insist on it.
+1 to 5x. I have no idea whether I'm in the minority here. I fully expect
that anytime I update a library (like SolrJ) that my program uses, I may need
to fix my code, and at the very least I will need to recompile my programs. If
the change is documented in whatever the package has for a CHANGES file, that's
even better.
So far I've been extraordinarily lucky in that I've only needed to make changes
to take advantage of new features, the code has always compiled successfully on
SolrJ updates. It's a bonus that I did not expect; I'm OK with minor changes
in the API. Large scale refactorings in a minor version update might bother
me, but only if they do not come with a major advancement in the library's
usability or capability.
> SolrClient.query() methods should throw IOException
> ---------------------------------------------------
>
> Key: SOLR-7151
> URL: https://issues.apache.org/jira/browse/SOLR-7151
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Priority: Minor
> Fix For: Trunk, 5.1
>
> Attachments: SOLR-7151.patch
>
>
> All the methods on SolrClient are declared as throwing SolrServerException
> (thrown if there's an error somewhere on the server), and IOException (thrown
> if there's a communication error), except for the QueryRequest methods.
> These swallow up IOException and repackage them in a SolrServerException.
> I think these are useful distinctions to make (you might want to retry on an
> IOException, but not on a SolrServerException), and we should make the query
> methods fall in line with the others.
> I'm not sure if this should go into 5.x as well as trunk, as it's a
> backwards-breaking change. I'm leaning towards yes, as it's a sufficiently
> useful API change that it's worth the break, but I'm not going to insist on
> it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
