juju/retry take 2 - looping

[Katherine Cox-Buday]

John Meinel <john at arbash-meinel.com> writes:

> The one things I'll specifically note about your "simple" example is
> that it doesn't actually handle errors. The fact that the "quick way
> to write it" is actually wrong is the specific argument of this
> thread.

Thanks for raising that point. I agree that coercing the developer into doing the right thing is an important point to consider when discussing these two approaches. I reject the fact that failed to do so in email as a straw-man argument as to how often this will occur.

> In your loop you have a way to generate a FinalResult, but no handling of the actual "I couldn't
> get a result". The way above that you can tell the loop failed would be to check if FinalResult
> doesn't have a valid value.

If I were truly writing this code in production, it would actually look more like this:

func foo() {
    /*...*/
    result, err := maybeSomeFunc(spec)
    if err != nil {
       return errors.Trace(err)
    }
    /*...*/
}


func maybeSomeFunc(spec retry.Spec) (interface{}, error) {
    var finalErr error
    for loop := retry.Loop(spec); loop.Next(); {
        result, err := SomeFunc(blah)
        if err != nil || resultNotGoodEnough(result) {
            finalErr = err
            continue
        }

        return result, nil
    }

    return nil, finalErr
}

And this doesn't take into account preemption, or the minutia of the domain-specific problem -- I might even write it differently depending on what I'm retrying. I.e. it's really hard to write a representative example. And that's kind of the point, right? We want to value composability for this very reason.

-- 
Katherine