-
Notifications
You must be signed in to change notification settings - Fork 1
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
Introduce api.Error type (and improve errors) #64
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not Michael Grace, but I thought I'd have a quick look while I'm browsing through URY stuff :) it looks mostly good to me, I just had a few questions about things.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any errors that need to be caught on closing a request body?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://stackoverflow.com/a/47294087/2586553
There are two things to consider: What would you do with it if you checked it and there was an error? And, what would the side-effects be if there was an error?
In most cases, for closing a response body, the answer to both questions is... absolutely nothing. If there's nothing you'd do if there was an error and the error has no appreciable impact, there's no reason to check it.
} | ||
|
||
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell, per controllers/api/v2.php
any successful response will have "status": "OK"
- though the converse isn't guaranteed (there are status
values other than FAIL
- see MyRadioException).
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