John Meinel <[email protected]> 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
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
