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.pen...@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@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
