[API Proposal]: Allow ILoggerProvider(s) to conditionally create ILoggers

[petrroll]

Background and motivation

Imagine you have logging setup so that all logging is supposed to be handled/go to one place. But some events you also want to handle separately.

.NET logging has support for that via multiple ILoggerProvider all of which are used to create a composite logger and then all are invoked for every log event.

This is, however, not conditional. An ILoggerProvider must always provide an ILogger instance, no matter the category. And so, even if you need two (default and your additional one) ILogger (via default your additional one ILoggerProvider) only for one category, you still need to live with two Loggers for every category. Probably implementing it as returning NullLogger for every not-desired category.

This is rather wasteful.

API Proposal

namespace Microsoft.Extensions.Logging;
// Maybe it should be separate interface not "super" interface, I'm not sure how to decide which is better
public interface IMaybelLoggerProvider : ILoggerProvider // I'm not good at naming things 😅
{
    /// <summary>
    /// Create a new <see cref="ILogger"/> instance if provider wants to handle this <param=categoryName>.
    /// </summary>
    /// <param name="categoryName">The category name for messages produced by the logger.</param>
    /// <returns>The instance of <see cref="ILogger"/> that was created or null.</returns>
    ILogger? TryCreateLogger(string categoryName);
}

API Usage

public class MyLoggerProvider : IMaybelLoggerProvider
{
    public ILogger CreateLogger(string categoryName) => new MyLogger();

    public void Dispose() { }

    public ILogger? TryCreateLogger(string categoryName)
        => categoryName == "TheOnlyCategoryWeAreInterestedIn" 
        ? CreateLogger(categoryName) 
        : null;
}

The LoggerFactory's LoggerInformation[] CreateLoggers(string categoryName) would also be adjusted to only create loggers where the provider returns not-null. And to invoke the Try version if available.

Alternative Designs

Separate interface instead of super interface :).

Alternatively, you can always just produce null loger as right now.

Risks

Complicate the API surface which can cause user confusion.

Creating array of loggers in performant and minimal-alloc (just the resulting array) will be more complex to do, as before running each provider the final amount of loggers is not known.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-logging
See info in area-owners.md if you want to be subscribed.

[tarekgh]

Why complicate things when you can simply use NullLogger for any category your provider doesn’t support? NullLogger is already optimized and always disabled, so there’s virtually no overhead in using it.

This is rather wasteful.

I disagree. You can use the NullLogger.Instance which will not allocate anything and will be disabled too.

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.

[tarekgh]

I’m closing this for now. If we see similar requests or demand in the future, we can revisit it.

[petrroll]

Yes, it does not allocate but there's some cost in iterating over a potentially long array of loggers and trying each of them. Furthermore it IMHO can confuse people, etc.

If many providers become interested in only their events then it's suddenly not viable. And that can easily happen in multiple big libraries situatoin (s.a. inside microsoft, we currently have like 5 and ideally'd have like 20+).

[tarekgh]

but there's some cost in iterating over a potentially long array of loggers and trying each of them.

Have you measured this in common scenarios to see if there's any meaningful overhead? I doubt it adds any noticeable cost, especially compared to the heavier operations typically performed by loggers.

Furthermore it IMHO can confuse people, etc.

I'm not sure about that. When you say "people," who are you referring to? Typically, applications enable loggers and collect logs accordingly—whether your interface is used or not shouldn't affect that behavior.

My main concern is that adding more interfaces makes the logging system more complex without providing any clear or significant benefit.

[petrroll]

I haven't. Fair enough :).

And I'm most recently referring to myself who got confused by this when trying to figure out how to enable double logging of the same event as two different categories + how to custom sample one of them.

(And moreover the original event being emitted from code I don't controll)

((Fair enough, not a super common scenario))