[jira] [Comment Edited] (SOLR-7151) SolrClient.query() methods should throw IOException

["Shawn Heisey (JIRA)" <ji...@apache.org>]

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

Shawn Heisey edited comment on SOLR-7151 at 2/24/15 1:58 PM:
-------------------------------------------------------------

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.

To put it another way: If CHANGES.txt informs me that I may not be able to do a drop-in jar replacement with that minor update, that's enough notice for me ... although I would have assumed that anyway.


was (Author: elyograg):
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org