[
https://issues.apache.org/jira/browse/SOLR-7151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14334957#comment-14334957
]
Mark Miller commented on SOLR-7151:
-----------------------------------
I think the tradeoffs have to be weighed pretty carefully. We want to get to
the point that you can do rolling upgrades and such, and back compat breaks,
while sometimes necessary, especially in the early days of APIs, need to become
more and more rare for point releases I think.
I'd like to start a new trend of annotating what API's can be counted on and
what not before long. We are great about http, but anything java is a mine
field. And soon we would like to support rolling upgrades to some degree.
In this case, I'm not sure the win is worth the break myself. But it also of
the type we have let slide before.
> 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
