Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RestClient asynchronous execution should not throw exceptions #23307

Merged
merged 2 commits into from
Feb 28, 2017

Conversation

tlrx
Copy link
Member

@tlrx tlrx commented Feb 22, 2017

The current implementation of RestClient.performAsync() methods can throw exceptions before the request is asynchronously executed. Since it only throws unchecked exceptions, it's easy for the user/dev to forget to catch them, leaving the listener in the wild... Instead I think async methods should never throw exceptions and should always call the listener onFailure() method.

The current implementation of RestClient.performAsync() methods can throw exceptions before the request is asynchronously executed. Since it only throws unchecked exceptions, it's easy for the user/dev to forget to catch them. Instead I think async methods should never throw exceptions and should always call the listener onFailure() method.
@tlrx tlrx added :Clients/Java Low Level REST Client Minimal dependencies Java Client for Elasticsearch >enhancement review v6.0.0-alpha1 labels Feb 22, 2017
@tlrx tlrx requested a review from javanna February 22, 2017 13:13
Copy link
Member

@javanna javanna left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left a small comment, LGTM otherwise

new HttpHost[]{new HttpHost("localhost", 9200)}, null, null);
}

class TestListener implements ResponseListener {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can use RestClient.SyncResponseListener here instead

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure

@javanna javanna added >bug and removed >enhancement labels Feb 22, 2017
@javanna
Copy link
Member

javanna commented Feb 22, 2017

I marked it as a bug, I think we should backport it too.

@elasticmachine
Copy link
Collaborator

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

@tlrx tlrx merged commit 9da8531 into elastic:master Feb 28, 2017
tlrx added a commit that referenced this pull request Feb 28, 2017
The current implementation of RestClient.performAsync() methods can throw exceptions before the request is asynchronously executed. Since it only throws unchecked exceptions, it's easy for the user/dev to forget to catch them. Instead I think async methods should never throw exceptions and should always call the listener onFailure() method.
tlrx added a commit that referenced this pull request Feb 28, 2017
The current implementation of RestClient.performAsync() methods can throw exceptions before the request is asynchronously executed. Since it only throws unchecked exceptions, it's easy for the user/dev to forget to catch them. Instead I think async methods should never throw exceptions and should always call the listener onFailure() method.
tlrx added a commit that referenced this pull request Feb 28, 2017
The current implementation of RestClient.performAsync() methods can throw exceptions before the request is asynchronously executed. Since it only throws unchecked exceptions, it's easy for the user/dev to forget to catch them. Instead I think async methods should never throw exceptions and should always call the listener onFailure() method.
@tlrx tlrx added the v5.2.2 label Feb 28, 2017
@tlrx tlrx deleted the rest-client-should-not-throw-exceptions branch February 28, 2017 09:27
tlrx added a commit that referenced this pull request Feb 28, 2017
 With  #23307, the expected exception is wrapped two times into a RuntimeException instead of being thrown directly.
tlrx added a commit that referenced this pull request Feb 28, 2017
 With  #23307, the expected exception is wrapped two times into a RuntimeException instead of being thrown directly.
tlrx added a commit that referenced this pull request Feb 28, 2017
 With  #23307, the expected exception is wrapped two times into a RuntimeException instead of being thrown directly.
tlrx added a commit that referenced this pull request Feb 28, 2017
 With  #23307, the expected exception is wrapped two times into a RuntimeException instead of being thrown directly.
@tlrx tlrx removed the v5.2.2 label Jun 22, 2017
@tlrx
Copy link
Member Author

tlrx commented Jun 22, 2017

Removing 5.2.2 label as this issue has not been packaged with 5.2.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants