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
retry with: linear_backoff(50, 1) |> take(5),
rescue_only: [
{:error, :some_retryable_reason},
{:error, :other_retryable_reason}
] do
foo()
after
_ -> :ok
else
error -> error
end
So - for some subset of errors attempt the retry, while for others give up instantly.
Currently it is impossible:
rescue_only works only for exceptions (foo would need to raise instead of returning {:error, reason})
atoms is for, well... atoms, not tuples (although with this interesting exception (if the first element of 2–elements tuple is a given atom the retry will kick in)
I can't see clear way of this situation. Some ideas:
third option, tuples, which would match any tuples specified by the user (any length, not necessarily (:error, reason}
allowing rescue_only to accept all sort of things, mixed - exceptions, atoms, tuples
What are your thoughts on that?
The text was updated successfully, but these errors were encountered:
Let's assume that we have a function like that:
What I'd like to express is roughly this:
So - for some subset of errors attempt the retry, while for others give up instantly.
Currently it is impossible:
rescue_only
works only for exceptions (foo
would need toraise
instead of returning{:error, reason}
)atoms
is for, well... atoms, not tuples (although with this interesting exception (if the first element of 2–elements tuple is a given atom the retry will kick in)I can't see clear way of this situation. Some ideas:
tuples
, which would match any tuples specified by the user (any length, not necessarily(:error, reason}
rescue_only
to accept all sort of things, mixed - exceptions, atoms, tuplesWhat are your thoughts on that?
The text was updated successfully, but these errors were encountered: