Standardise the error return from http request

[jasonkwh]

Is your feature request related to a problem? Please describe. Hey there. I want this because I need to do a error handling of the gql request. Situations like, if the request is returning 429 error, the program should do a retry, etc. However the current code is returningfmt.Errorf("returned error %v: %s", httpResp.Status, respBody). It is not helping the situation. It makes error handling complicated. Can we return the standard error so that can help the user better handling the errors?

Describe the solution you'd like We can do a simple enum. Or we can create a new error object includes the http status code + error info (that includes the resp body).

It will be really nice if we can have such feature. Otherwise I will just fork the code and create my derivatives. Thanks.

[benjaminjkraft]

That seems like a sensible thing to add, but I'm not sure offhand what the API would look like. We could add an As-able error type I guess? What do you mean by "the standard error"? Does net/http, or some other stdlib package, have a thing we should be using?

BTW, you can already (a) get direct access to the error and/or (b) retry it by writing your own graphql.Client, or passing a modified http.Client which, say, retries on 429. But I can see how sometimes you would want to know the status code in the application code instead.

[jasonkwh]

I mean, we can standardise the error messages and return those error messages when something is happening.

On my situation, at the moment i am using strings.prefix to match if there is a 429 error. While implementing the standard error messages, I can just compare the returned error with the gql client provided error. It's a nicer way to handle errors isn't it?