juju/retry take 2 - looping

[John Meinel]

As commented on the pull request, passing 'err' into Next() initially feels
weird, but it allows a big improvement to whether the loop exited because
we ran out of retries, or it exited because the request succeeded.
(loop.Error() tells us either way.)

I wonder if we want to push harder on always having a Stop channel, as
*production* code should probably always have a way to stop early.

John
=:->

On Thu, Oct 20, 2016 at 7:09 AM, Tim Penhey <tim.penhey at canonical.com>
wrote:

> Hi folks,
>
> https://github.com/juju/retry/pull/5/files
>
> As often is the case, the pure solution is not always the best. What
> seemed initially like the best approach didn't end up that way.
>
> Both Katherine and Roger had other retry proposals that got me thinking
> about changes to the juju/retry package. The stale-mate from the tech board
> made me want to try another approach that I thought about while walking the
> dog today.
>
> I wanted the security and fall-back of validation of the various looping
> attributes, while making the call site much more obvious.
> The pull request has the result of this attempt.
>
> It is by no means perfect, but an improvement I think. I was able to
> trivially reimplement retry.Call with the retry.Loop concept with no test
> changes.
>
> The tests are probably the best way to look at the usage.
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20161020/0c9825d8/attachment.html>