roger peppe <[email protected]> writes: > There's a fourth way that you haven't mentioned, which fits somewhere > in between 1 and 2 I think (it was the first explicit general retry > code in Juju AFAIK), which is utils.Attempt. > > I'd suggest that the way it's used matches the pattern you'd like to > write quite well: > > for attempt := strategy.State(); attempt.Next(); { Do something }
Thanks, Roger, I had missed that one. utils.Attempt would be my next preference, but it would have to be taught how to be interruptable via channel. I also feel that because so much of Go is oriented towards channels, exposing the wait via a channel rather than a function makes sense, but I don't immediately have a use-case in mind. > > AFAIR this pattern was arrived at after some discussion between myself > and Gustavo. At the time I was thinking of some kind of callback-based > scheme like the others schemes you mention, but I think that leaving > the caller in control and the loop explicit is actually nicer - the > logic is clear to the reader and more composable with other primitives > (it is also a good match for the pattern you propose). I strongly agree with this. In my estimation, favoring composability and inline code is much clearer and maintainable than piling one abstractions on another. > How about making AttemptStrategy a little more flexible? It looks like we've standardized on juju/retry. I don't have the historical context in my cache to know why we've rewritten retries 3 times now o.0 -- Katherine -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
