Lurgle.Logging v1.2.4 Update - Rethinking usage patterns

A while back I updated Lurgle.Logging to support new logging patterns. I've sat on it for a while, but some aspects of this weren't as well thought through as they could have been. Specifically, the idea of passing:

Log.Error(ex, "Oh no! An error! {Message}", Logging.NewCorrelationId(), args: ex.Message);
Log.Error(ex, "Oh no! Barry had an error! {Message)", "Barry", args: ex.Message);

was somewhat flawed. I allowed these static methods to take arguments, but the auto parameters for method name, source line number, and source file path would interfere with this, so that while one argument worked fine, you couldn't readily pass multiple arguments.

That's pretty annoying, and not readily solvable without sacrificing the utility of capturing the calling method and so on. It's really the point of these methods, so it needed action.

Hence - while I generally prefer not to do breaking changes - I've wound the patterns back somewhat. You can't pass log templates to these static methods anymore - but you can still use them as a shortcut to pass the log level. 

Hence the log patterns called out from LurgleTest in the original post have morphed somewhat - but they retain their Fluent nature, and I feel they're a bit more fully baked.

            Log.Level().Add("{AppName:l} v{AppVersion:l} starting ...");
            Log.Add("Simple information log");
            Log.Add(LurgLevel.Debug, "Simple debug log");
            Log.Information().Add("Information event");
            Log.Information().Add("Information event with {Properties:l}", args: "Properties");
            Log.Verbose().Add("Verbose event");
            Log.Verbose().Add("Verbose event with {Properties:l}", args: "Properties");
            Log.Debug().Add("Debug event");
            Log.Debug().Add("Debug event with {Properties:l}", args: "Properties");
            Log.Warning().Add("Warning event");
            Log.Warning().Add("Warning event with {Properties:l}", args: "Properties");
            Log.Error().Add("Error event");
            Log.Error().Add("Error event with {Properties:l}", args: "Properties");
            Log.Fatal().Add("Fatal event");
            Log.Fatal().Add("Fatal event with {Properties:l}", args: "Properties");
            Log.AddProperty("Barry", "Barry").Warning("Warning event with {Barry:l}");
            Log.Error(new ArgumentOutOfRangeException(nameof(test))).Add("Exception: {Message:l}", args: "Error Message");
            Log.AddProperty(LurgLevel.Error, "Barry", "Barry").Add("Log an {Error:l}", "Error");
            Log.AddProperty(LurgLevel.Debug, "Barry", "Barry").Add("Just pass the log template with {Barry:l}");
            Log.AddProperty(new ArgumentOutOfRangeException(nameof(test)), "Barry", "Barry")
                .Add("Pass an exception with {Barry:l}");
            Log.AddProperty(test).AddProperty("Barry", "Barry").Add(
                "{Barry:l} wants to pass a dictionary that results in the TestDictKey property having {TestDictKey}");
            Log.Level().Warning("Override the event level and specify params like {Test:l}", "Test");

Functionally, Log.Information / Verbose / Debug / Error / Fatal all now work more or less like Level and Exception, but with an implicit LurgLevel that matches the method. You can pass an exception, CorrelationId, and a showMethod like the older methods - but they no longer accept log templates or arguments.

The one exception here is Log.Add() which can pass a message template, and optionally accept an Exception and/or LurgLevel. Otherwise - this has been reverted to old behaviour, where it did not accept arguments. Log.Add is for simple usages without passing arguments.

The net effect is a more fully baked Lurgle that doesn't leave you with strange, unexpected, or even annoying results. 

And the fancy links below, if you feel brave enough to behold the awesomeness of Lurgle and are somehow unable to use Nuget to add it to your project ...




You may also like:

Lurgle.Logging v1.2.1 - More logging patterns for your Lurgle convenience

Lurgle approach compared to Serilog Following on from the v1.2.0 multi-threaded correlation release, I thought about whether we could further improve how we interface with Lurgle.Logging. The general approach was to maintain a static interface to logging that would allow us to capture key properties for logging, that would provide nicely...

Lurgle.Logging v1.2.0 - Multi-threaded correlation ids are now a thing

Implementing Multi-Threaded Lurgles If we revisit my example from earlier, we'll see a much simpler implementation for multi-threaded code; Log.Level().Add("Here is my log entry"); Log.Level(LurgLevel.Error).Add("Oh no! An error!"); Log.Level().Add("Phew ... moment passed"); Log.Level(correlationId: Logging.NewCorrelationId()).Add("After all that, I'd really like a different correlation id"); Log.Level(LurgLevel.Debug).Add("CorrelationId is {CorrelationId}"); You can see from...

Lurgle.Logging - a standardised Serilog implementation with extra goodies!

Logging is important Logging is a really important, oft-neglected, aspect of business applications. I can't state that enough. If you don't have good logging, you can't troubleshoot and debug problems, and you have little chance of seeing what's actually going on in your enterprise. In Structured Logging with Seq and Serilog,...