Skip to content
This repository has been archived by the owner on Dec 1, 2021. It is now read-only.

Sprint that wraps Fprint #28

Closed
dancingeek opened this issue May 23, 2016 · 4 comments
Closed

Sprint that wraps Fprint #28

dancingeek opened this issue May 23, 2016 · 4 comments

Comments

@dancingeek
Copy link

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.

@davecheney
Copy link
Member

Thank you for raising this issue. At the moment my position oj adding a sprint wrapper has not changed, for the following reasons

  • it really is trivial to right, and I feel if this package was to be proposed for the stdlib, this function would not make the cut so it's best to get used to living without it now
  • I agree that a string form is more useful than an io.writer form, but as we saw while people want the information as a string, they have conflicting requirements on the format of that string; multiline vs single line, files vs paths, etc. The original version was removed to side step this underspecified requirement.
  • recently errrs in this package grew the ability to record their entire stack trace, but this information is not yet surfaced by this package, solving that problem will impact Fprint (probably replacing it entirely) so adding an sprint helper on top would be short lived.

Thank you for your time

Dave

@davecheney
Copy link
Member

Urg, please ignore the typos, there is no edit option in the mobile version of github.

@dancingeek
Copy link
Author

Thanks for the reply. I will close this issue and await the future changes.

@davecheney
Copy link
Member

Hello,

I wanted to draw your attention to #37 as a possible replacement for Fprintf and others. #37 is not a complete implementation, but the plan is to defer any formatting or layout decisions to the fmt package, controlled by various formatting modifiers.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants