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

Propagate server response to exception #37

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

uvsmtid
Copy link

@uvsmtid uvsmtid commented Sep 13, 2019

It is often the case (especially for HTTP status 500) when many details are hidden in the headers/body of the HTTP server response.

Since OkHttp library already constructs and provides the Response object, it makes sense to propagate it to the library's client code via UnsuccessfulResponseException.

@uvsmtid
Copy link
Author

uvsmtid commented Sep 13, 2019

Use case:
We are integrating with some enterprise server which has various non-HTTP (service-specific) error codes provided in the body of its response as JSON object. Our client code has to deal with some generic HTTP status code but act differently depending on the content of this JSON object. Changing this server-side behaviour is outside of our control. Being able to extract HTTP response (body) from UnsuccessfulResponseException gives us the necessary flexibility.

public UnsuccessfulResponseException(int code) {
super("Unsuccessful response code received from stream: " + code);
this.code = code;
this(buildSurrogateResponse(code));
Copy link
Contributor

Choose a reason for hiding this comment

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

I would not do this; it'd be preferable to just let getResponse() return null in this case. The rationale can't be backward compatibility, since old code that uses this deprecated constructor couldn't be looking for a Response.

Copy link
Author

Choose a reason for hiding this comment

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

Actually, I also realized that the whole PR didn't work.

I think due to the async fact that the whole response is not available yet when UnsuccessfulResponseException is created within the library's code (unlike the error code).
In other words, there are more changes needed (even if this constructor change is reverted).

So far, we happily used the library without this change anyway - @eli-darkly , I'm OK if it is rejected (when I need it badly, I'll propose proper change).

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm. Can you say more about what specifically was not working? I would expect that trying to read the body would not work, since other code might already have read the body - that's just an expected issue whenever you share a Response around. But I would have expected the headers to be available.

Copy link
Contributor

@eli-darkly eli-darkly left a comment

Choose a reason for hiding this comment

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

Sorry it took us a while to get to this. It seems like a potentially useful feature but I left one comment about an implementation concern.

LaunchDarklyCI pushed a commit that referenced this pull request Jun 2, 2020
(#2) add code coverage reports, improve CI
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants