Tim Penhey <[email protected]> writes:
> The rationale behind that is to make the the library handle the 80%
> case easily. The main reason of passing the error into Next is so you
> don't have to do the check and explicit break within the loop.
I will argue here that this goes against a core principle of Go which is to be
informed and care about your error path.
> Sure, but this could be trivially handled by assigning something to
> err (consider if we made a public error in the retry package for
> this):
>
> var result Foo
> var err error
> for loop := retry.Loop(spec); loop.Next(err); {
> result, err = SomeFunc(blah)
> if err == nil && resultNotGoodEnough(result) {
> err = retry.ErrTryAgain
> }
> }
> if err != nil {
> // what ever
> }
> // continue using result
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.
--
Katherine
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
