Don’t throw errors for “normal” errors #56
Conversation
Return the more-standard elixir tuple of
{:error, message} and let the user decide what
they want to do with it.
We still raise hard errors for truly unrecoverable
things like missing keys and/or configuration
options.
|
@parroty This is an initial pass. Let me know what you think and what needs revisions. |
| code: code, message: message, reset_at: reset_at, reset_in: reset_in | ||
| _ -> | ||
| raise ExTwitter.Error, code: code, message: message | ||
| {:error, "RateLimitExceeded: #{message}, reset at: #{reset_at}, reset in: #{reset_in}"} |
There was a problem hiding this comment.
In this, and other similar places, we're losing a lot of exception information by throwing it all into a string. reset_at and reset_in are used by clients to back off connections until the rate limiter allows, so it's useful to have this information in the tuple returned. Perhaps we should be doing the following instead?
{:error, :rate_limit_exceeded, %{code: code, message: message, reset_in: reset_in, reset_at: reset_at}}
I'm not sure if throwing all this info into an error tuple is the most 'Elixary' way of doing this? Has anyone got better examples from other projects?
There was a problem hiding this comment.
having the http status code would be helpful as well.
There was a problem hiding this comment.
Agreed, this PR was only to mimic the existing error messaging behavior while converting to stop throwing errors. Send back a tuple or map with extra metadata is greatly preferred.
|
@tomtaylor I've recently tackled this change in ExTrello https://github.com/ChrisYammine/ex_trello/blob/master/lib/ex_trello/api/base.ex Maybe it can act as inspiration :) |
|
@chrisyammine thanks - that looks useful! |
|
Very sorry being late to respond. I'll be looking into this item as for v0.8.0. |
|
Hi. I was working on this item for pushing 0.8.0, but couldn't well resolve the following concerns.
I'm afraid but please let me revert tentatively, and rework on this item. I'm checking the example @chrisyammine provided, and thinking about similar approach (with this macro approach, I'm wondering if Sorry again for leaving it long time and making like this one. |
|
@parroty @cpjolicoeur Hey guys, has there been any movement on this issue? I suppose, by now, it will become a breaking change for many consumers, but I would really love to see trivial, recoverable errors being returned to the customer instead of potentially nuking an entire process. |
Return the more-standard elixir tuple of
{:error, message} and let the user decide what
they want to do with it.
We still raise hard errors for truly unrecoverable
things like missing keys and/or configuration
options.
[Fix #52]