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

Introduce api.Error type (and improve errors) #64

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

Conversation

markspolakovs
Copy link
Member

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

something, err := session.DoAThing()
var apiErr api.Error
if errors.As(err, &apiErr) {
  // request succeeded, but MyRadio returned an error
  // do something with apiErr.Status
} else if err != nil {
  // something went wrong with making the request itself
}

Copy link
Member

@MattWindsor91 MattWindsor91 left a 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()
Copy link
Member

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?

Copy link
Member Author

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.

api/api.go Show resolved Hide resolved
}

// 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 {
Copy link
Member

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.)

Copy link
Member Author

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).

api/errors.go Show resolved Hide resolved
@MattWindsor91
Copy link
Member

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.

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.

3 participants