juju/retry take 2 - looping

[roger peppe]

On 25 October 2016 at 22:40, Tim Penhey <tim.penhey at canonical.com> wrote:
> On 26/10/16 10:30, Katherine Cox-Buday wrote:
>>
>> I think this is a hint that this is the wrong approach. The edge-cases
>> begin showing the cracks in the abstraction and end up making the code more
>> complex. Consider your example instead of:
>>
>> var finalResult Foo
>> for loop := retry.Loop(spec); loop.Next(); {
>>     result, err := SomeFunc(blah)
>>     if err != nil || resultNotGoodEnough(result) {
>>         continue
>>     }
>>
>>         finalResult = result
>>     break
>> }
>>
>> There are no special errors, no mixing of concerns, just a boring
>> imperative loop. It works like any other loop written in Go.
>
>
> I was trying to reduce the need for continue/break. Forcing continue/break
> does not make it like all boring imperative loops.
>
> The err used inside the loop should be declared outside if you want to be
> able to see if the loop succeeded or failed.

Honestly, it's just a loop that tries *something* several times with delays.
It's not always because of something that looks like an error. Trying to make it
look like an error makes the primitive less easy to understand
and more considerably more difficult to use in some cases
(consider retrying because of a particular HTTP response code).

  rog.