This repository has been archived by the owner on Dec 1, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 698
Sprint that wraps Fprint #28
Comments
Thank you for raising this issue. At the moment my position oj adding a sprint wrapper has not changed, for the following reasons
Thank you for your time Dave |
Urg, please ignore the typos, there is no edit option in the mobile version of github. |
Thanks for the reply. I will close this issue and await the future changes. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
Dave Cheney cited the reason for denial being
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.
The text was updated successfully, but these errors were encountered: