Skip to content

Conversation

IanYates
Copy link
Contributor

What issue does this PR address?
Adds a static Log.None property as per the discussion in #1105

Does this PR introduce a breaking change?
No

Please check if the PR fulfills these requirements

  • The commit follows our guidelines
  • Unit Tests for the changes have been added (for bug fixes / features)

Other information:
Basic change to stash a SilentLogger instance in a private static variable on the Log class. That instance is used as the initial value of the Logger property. The same instance is then exposed via the None property. CloseAndFlush() was modified to reset back to this instance rather than creating yet another SilentLogger instance.

Comments were updated where appropriate and code style was preserved.

I've added tests to ensure that the None property is initialised properly. I've also ensured via a test that initialisation of the Logger property doesn't affect the None property.
Finally I've ensured that CloseAndFlush doesn't corrupt the logger stored and accessible via the None property by checking that it remains a SilentLogger instance and that we can invoke it without raising an exception.

I think there are lines of words here than lines of code changed in the PR. All tests (on my machine) seem to pass in the various framework versions.

Thanks 💯

…ests. Allowed for slight simplification of _logger initialization and CloseAndFlush() implementation
@IanYates
Copy link
Contributor Author

Hmmm - AppVeyor failed in an area that I don't think I affected. ContextPropertiesCrossAsyncCalls... Travis CI seems happy (as did my PC).

@nblumhardt
Copy link
Member

Thanks, Ian!

Since this is more of a plumbing feature, than something that will be used regularly by callers of Log, I'd thought perhaps Logger.None rather than Log.None might keep it tucked away?

@@ -1201,5 +1209,16 @@ public static bool BindProperty(string propertyName, object value, bool destruct
{
return Logger.BindProperty(propertyName, value, destructureObjects, out property);
}

/// <summary>
/// An <see cref="ILogger"/> instance that silently ignores all log messages
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick, could use a . here.

Perhaps we could try "that efficiently ignores all method calls"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍
Shall do

@IanYates
Copy link
Contributor Author

Not sure why I ended up on Log.None... Logger.None makes more sense. Shall amend this evening. Thanks

@IanYates
Copy link
Contributor Author

Closing in favour of PR #1110 instead

@IanYates IanYates closed this Feb 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants