-
Notifications
You must be signed in to change notification settings - Fork 123
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Accept no-op null arguments in ScopedLoggingContext.Builder.
All Flogger fluent method calls accept no-op arguments to permit conditionally ignoring a method call without splitting the method chain. While the builder can be assigned to a local variable to conditionally apply methods, this is inconsistent with other usage of Flogger, and discouraged by javadoc. https://google.github.io/flogger/best_practice.html#no-split RELNOTES=Accept no-op null arguments in ScopedLoggingContext.Builder. PiperOrigin-RevId: 557923868
- Loading branch information
1 parent
0e3818b
commit 5aa0649
Showing
2 changed files
with
64 additions
and
13 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5aa0649
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A regards https://google.github.io/flogger/best_practice.html#no-split
The idea of not needing to split fluent APIs does not mean they should accept null arguments if there is a perfectly good "no-op" instance that could have been passed.
For example,
withStackTrace()
accepts theNONE
enum and rejectsnull
, and forTags
, theTags.empty()
singleton instance is always available to be passed.This also isn't the logging API, and the "no split" advice was written primarily for that (though it is probably good advice in general).
When making contexts I felt that there was less likelihood a user would be conditionally adding metadata values (if you are creating a context with no values, it's better to just not create the context). E.g. I was imagining that users will do:
I'd be interested to know if this change came from a real situation in which a user needed the ability to provide no-op values, and which values these were?