Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add filtered leveled logging and error promotion #252
Adds a couple new options to levels.Levels, including:
Creates an ordered enumeration of LogLevels from Debug up to Crit,
To detect the presence of errors in the context, I had to add a
Thanks for the well documented PR!
I don't have time for a full review, but I believe returning the levelCommitted logger from the Levels methods will interact badly with log.DefaultCaller. Can you add test code to check that. See #131 for information about when we changed levels.Levels to work correctly with log.DefaultCaller. We should try not to cause a regression in this area.
I will review in more detail when I get the time.
@ChrisHines Your intuition is correct, it messes up
I'm racking my brain trying to come up with a workaround for this that doesn't involve tacking on more junk to the public API of
We can jettison the error promotion, and this becomes super easy: in
I will consider it more this weekend but I'd love it if you had some ideas.
Possibly the cleanest solution I can come up with is to add some kind of
The hook would be of the signature
Which would allow consumer packages to add a hook that checks and potentially replaces the keyvals that are about to be logged, and bails out on an error, which could include "don't log this because of the log level."
But it feels clunky and complicated and overkill to support something that isn't a prominent use case.
@bishoprook I agree that
The idea you mentioned in #250 to avoid evaluation of expensive
logger := log.NewLogfmtLogger(w) logger = LazyValueLogger(logger) logger = levels.NewLevelFilterLogger(logger, logLevel) logger = levels.NewEscalateErrLogger(logger) lvllog := levels.New(logger).With("t", log.DefaultTimestampUTC, "caller", log.DefaultCaller)
In this way
I am not suggesting we add