You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It makes more readable code if the annotation in stop_for_status is not an error message but an assertion statement. When writing code we don't know the error, we only know what it was that we were trying to do in the request. For example:
stop_for_status(req, "download spreadsheet")
## Error: download spreadsheet failure: not found (HTTP 404)
Sorry for not being more clear about this. I think the current implementation stop_for_status(x, "Spreadsheet not found") is often impractical because typically we can't know the exact error cause in advance. If we do have a mapping between status code and error messages, we are better of using http_condition.
The goal of stop_for_status messages would be to encourage authors of client libraries to let the user know what/where an error was created. Generic http errors messages are not too helpful for high level wrappers:
generate_report(foo, bar, "my_data")
## Error: Permission Denied (HTTP 401)
Instead, the user would see a more informative message that states what exactly what went wrong:
It's just a matter of getting the English phrasing right so it doesn't feel too awkward. I feel like just tacking "failed" on to the end is suboptimal - i.e. you want goal = "download spreadsheet", so maybe
Failed to download spreadsheet
Failed to issue request
But the default isn't quite right - the request was issued successfully, just the response wasn't as you'd hoped.