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
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}
allowing
rescue_only
to accept all sort of things, mixed - exceptions, atoms, tuplesWhat are your thoughts on that?