EncoderConfig and AtomicLevel validation added #791
Conversation
Codecov Report
@@ Coverage Diff @@
## master #791 +/- ##
==========================================
+ Coverage 98.22% 98.31% +0.08%
==========================================
Files 43 43
Lines 2306 2310 +4
==========================================
+ Hits 2265 2271 +6
+ Misses 33 32 -1
+ Partials 8 7 -1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Hello! Thanks for the PR. I've left a couple comments. In particular, I'm not sure whether we should fall back to a default behavior or return an error. Although the default for log levels is not very controversial, the default for the time encoder is. Since different users have different requirements, we may want to err on the side of requiring that they be explicitly specified.
config.go
Outdated
| cfg.Level = NewAtomicLevelAt(InfoLevel) | ||
| if cfg.Development { | ||
| cfg.Level = NewAtomicLevelAt(DebugLevel) |
There was a problem hiding this comment.
Should we return an error instead?
If we prefer to add a default behavior for Level when unspecified, we'd probably want to document it on Config.Level.
There was a problem hiding this comment.
I could see InfoLevel as default in ProductionConfig and DebugLevel in DevelopmentConfig, that's why thought of adding the same defaults here.
Let's return an error then!
config.go
Outdated
| @@ -239,5 +246,12 @@ func (cfg Config) openSinks() (zapcore.WriteSyncer, zapcore.WriteSyncer, error) | |||
| } | |||
|
|
|||
| func (cfg Config) buildEncoder() (zapcore.Encoder, error) { | |||
| if cfg.EncoderConfig.TimeKey != "" && cfg.EncoderConfig.EncodeTime == nil { | |||
| cfg.EncoderConfig.EncodeTime = zapcore.EpochTimeEncoder | |||
There was a problem hiding this comment.
Same here. It's not obvious why we pick epoch for production and ISO8601 for development. Perhaps an error would be preferable?
There was a problem hiding this comment.
NewDevelopmentEncoderConfig specifies ISO8601TimeEncoder by default. I have not made any explicit choices here. But, let's return an error.
abhinav
requested review from
mway and
prashantv
and removed request for
prashantv
|
Agree with @abhinav -- I think To avoid any surprises, returning an error seems best. We should also add unit tests to validate the new behaviour. Thanks! |
config.go
Outdated
| @@ -239,5 +244,9 @@ func (cfg Config) openSinks() (zapcore.WriteSyncer, zapcore.WriteSyncer, error) | |||
| } | |||
|
|
|||
| func (cfg Config) buildEncoder() (zapcore.Encoder, error) { | |||
| if cfg.EncoderConfig.TimeKey != "" && cfg.EncoderConfig.EncodeTime == nil { | |||
There was a problem hiding this comment.
It seems that newEncoder is the ultimate constructor for zapcore.Encoder given
an EncoderConfig. We should maybe move this check to the newEncoder function,
leaving buildEncoder unchanged.
|
|
`if a == b{} { ... }` is syntactically invalid Go.
This adds validation for Level and EncoderConfig.EncoderTime when building a logger from a zap.Config. Resolves uber-go#777 Co-authored-by: Abhinav Gupta <abg@uber.com>
Resolves #777