-
Notifications
You must be signed in to change notification settings - Fork 715
Sprint that wraps Fprint #28
Description
This topic was partially covered in #20
Given the ping-ponging of that issue I wanted to create a new issue that was solely focused on the smallish proposed Sprint utility that could conceivably take the form:
func Sprint(err error) string {
var b bytes.Buffer
errors.Fprint(&b, err)
return b.String()
}
Dave Cheney cited the reason for denial being
Fprintf is more general and can be used to implement the three line helper you suggested.
While this is true, I would like to have a thought experiment on the usage of the errors library. One of the primary benefits of this library is the ability to wrap errors as they pass up a call stack in order to provide better contextual information when the error bubbles up to a stopping point. This contextual information is then only useful if is is then extracted and reported in some way.
My experience has been two-fold: That this reporting is done by passing the generated information to a logging framework, and that logging frameworks don't expose an io.Writer. This is certainly true of the log package. So while the existing Fprint function is certainly more flexible, it is much less useful. This leaves what I believe is the majority of consumers with the choice of repeating the three-liner ad-nauseam, or creating a utility to wrap errors and import that utility (of course there will also be cases of doing both in the same code base).
I understand and respect that the bar is high for increasing the API footprint of this library. I ask that you reconsider this proposal as it would make the greatest utility that the errors package provides fit better with the part of the standard library it will primarily be used in conjunction with.