The backoffClient here is specific to redis. Let's just return b.client.String(). The string is used to identify a client type + endpoint on error. The actual error message message contains the reason. Printing additional state would be more helpful in form of debug messages when the next connection attempt starts/fails.

@urso as a go noob I'm a little confused by this. In most languages the canonical String()/toString() function is generally for debugging. Usually if you need a specific formatting of an object you have that logic at a higher level.

Are we sure we want to make String()'s implementation tightly coupled to this specific error message?

It seems to me like we should just not have made this stringer-like interface, and had the print function traverse the object graph itself and format things the specific way it would like them to be formatted.

We mostly use String to print and identify an object. In go we also have alternative formatting supporting using the fmt package. When using any fmt.X methods, it checks if your type implements fmt.Formatter. This adds additional formatting capabilities by passing the format pattern to the Formatter. When using fmt.XPrintf, one normally uses:

• %v: default representation
• %+v: which asks for more details
• %#v: which is interpreted by fmt and will add the struct name + print each field by name.

If fmt.Formatter is not implemented, %v will fallback to String() string (fmt.Stringer interface), and %#v will fallback to GoString() string (fmt.GoStringer interface).

See package documentation of fmt.