Open wooster11 opened 5 months ago
Thanks for raising this. Serilog needs the message and exception separately, so my guess is that this is done this way to avoid redundantly stringifying the exception into the message.
If there's a path to obtaining the behavior you want without breaking any existing consumers of the library (i.e. by unexpectedly changing the way events are constructed) it could definitely be considered, if you're keen to dig in deeper.
Otherwise, I suspect your best option might be to wrap SerilogLoggerProvider
and adapt it using your own implementation of the Log
method.
HTH!
In the AsLoggableValue method of the SerilogLogger, the formatter delegate is always invoked with the exception parameter as null. This causes issues if the Exception object is used in the formatter delegate that gets passed into a "Log" call. Is there a specific design decision for this?
This is a very contrived example of when this fails. If my application uses Serilog for logging but needs to pass a Microsoft.Extensions.Logging.ILogger into a class library of some kind for logging, it's possible that the class library will fail if it expects the exception to be there and formattable. The class library should handle the null reference through a null check, but this will always be true, and the exception will never be formatted to be logged even when expected.
Example code of a call that will fail: