-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zap integration (again) #23
Comments
When displaying errors to users, it's nice not to have a single line of errors separated by semicolons. I don't think It usually means more verbose output, but more verbose could mean anything, and I think the handling of errors for this package fits in with that definition. The more I think about it, the more it seems like to really solve uber-go/zap#460, we really want to identify the specific error rather than using a generic interface which doesn't convey much about the underlying data? |
Collating some ideas from uber-go/zap#460, I think there are two solutions on the table right now.
Given the number of error packages out in the world, I'm inclined toward (2). This keeps the user experience of both packages nice, reduces coupling, keeps zap's default output terse, and generally behaves as most users expect. |
fmt.Formatter
implementation
Approach 2 sounds reasonable to me. We'll need to be able to argue that the output is not part of the API contract |
The more I think about this, the more it seems like we need to make zap more flexible and allow users to choose what they want. I think the absolute minimum that
On the other hand, I would also like to:
Given no options, I think the safest option is to do the minimum. However, we should think about allowing custom error encoding (and possibly allow these to be stacked) so users can have |
I think we can accomplish all four goals (nil handling, Unfortunately, we'll have to include |
Following the discussions on #460, uber-go/multierr#6, and (most recently) uber-go/multierr#23, reduce log verbosity for `multierr`. This is fully backward-compatible with the last released version of zap. The small changes introduced here do two things: 1. First, we either report `errorCauses` or `errorVerbose`, but not both. 2. Second, we prefer `errorCauses` to `errorVerbose`. I think that this addresses our top-level wants without breaking any interfaces or removing behavior we've already shipped. If we ever decide to cut a new major release of zap, we should treat errors like durations and times - they're special types for which users choose a formatter. In a future release, we can add an `ErrorEncoder` interface that the JSON encoder and console encoder implement, and make the error field attempt an upcast into that type. That would let the user supply their own error encoder (much like they supply their own time and duration encoders now). Even if we do that, though, I suspect that we'll want to preserve the behavior here as the default.
Sure, I think we can achieve pretty much what we want by skipping verbose for Regarding the multiple types, I intended to avoid the issue by having it add the field |
Following the discussions on #460, uber-go/multierr#6, and (most recently) uber-go/multierr#23, reduce log verbosity for `multierr`. This is fully backward-compatible with the last released version of zap. The small changes introduced here do two things: 1. First, we either report `errorCauses` or `errorVerbose`, but not both. 2. Second, we prefer `errorCauses` to `errorVerbose`. I think that this addresses our top-level wants without breaking any interfaces or removing behavior we've already shipped. If we ever decide to cut a new major release of zap, we should treat errors like durations and times - they're special types for which users choose a formatter. In a future release, we can add an `ErrorEncoder` interface that the JSON encoder and console encoder implement, and make the error field attempt an upcast into that type. That would let the user supply their own error encoder (much like they supply their own time and duration encoders now). Even if we do that, though, I suspect that we'll want to preserve the behavior here as the default.
Currently, errors produced by this package implement
fmt.Formatter
with special support for the"%+v"
format. We should consider removing this support, since it doesn't actually add any information (which is typically the purpose of the+
flag).This came up because it makes logging these errors with zap particularly verbose - see post-merge discussion on uber-go/zap#460.
The text was updated successfully, but these errors were encountered: