Introduce api.Error type (and improve errors) #64
Conversation
| res, err := client.Do(req) | ||
| if err != nil { | ||
| return &Response{err: err} | ||
| return &Response{err: fmt.Errorf("failed to perform HTTP request: %w", err)} | ||
| } | ||
| defer res.Body.Close() |
There was a problem hiding this comment.
Are there any errors that need to be caught on closing a request body?
| @@ -178,38 +178,38 @@ func (s *authedRequester) Do(r *Request) *Response { | |||
| theurl.RawQuery = encodedParams | |||
| } | |||
| req, err := http.NewRequest(reqMethod, theurl.String(), bytes.NewReader(r.Body.Bytes())) | |||
| if err != nil { | |||
There was a problem hiding this comment.
I presume the old behaviour of setting the Content-Type header before bailing for the error was a bug?
There was a problem hiding this comment.
I presume it would have been, I would imagine that NewRequest would return (nil, error) and thus we'd try to access Header on a nil req.
| } | ||
|
|
||
| // Even if the result is non-200 we still want to try to unmarshal the response, to have a more descriptive error | ||
| var response struct { |
There was a problem hiding this comment.
Are there any situations where the response coming back from MyRadio states that it is not OK in the payload but OK in the HTTP status, or vice versa? Am just wondering about the fact that there is now only one check at the response body level and nothing on the HTTP code directly.
(Presumably those would be bugs in MyRadio, mind. It seems kind of weird to have that redundancy, but it's been so long since I looked at MyRadio that I don't even know anymore.)
|
|
||
| // Error is the error type returned when API requests result in an error. | ||
| type Error struct { | ||
| Endpoint string |
There was a problem hiding this comment.
Could the fields be commented, eg. making clear that Code is the HTTP status code coming back from the MyRadio response but Payload is (I guess) the raw description string coming out of MyRadio?
|
I ran into the problem of missing error granularity again while trying to work on 2016-site's podcast handling, so it'd definitely be nice to have. |
This will let downstream consumers handle the different MyRadio response codes differently (for example, 2016-site rendering a 404 when MyRadio sends a 404, rather than a 404 for everything). Intended usage is