-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception thrown in SerilogLogger when non-zero incorrect number of parameters is used. #164
Comments
Hi George, thanks for the heads-up! I think in the long run, being consistent with the rest of the MEL sinks is probably the way to go, here (in case, for example, MEL centralizes recording of these kinds of exceptions). I'm not sure though whether we should still behave this way when the If the latter fix is required, and had the effect of modifying the |
Hey thanks for the speedy reply! I think you're right - and it sounds like a pretty reasonable idea to stay consistent with MEL when using a MEL factory. I haven't taken a look at how the SelfLog pipe might work yet - can the factory capture the exceptions or would it need to tell the logger to do it? If that makes sense :). Changing the behaviour of |
Resolves #164 - suppress exceptions from FormattedLogValues
Hello I am pretty new to Serilog as I have used log4net for the last decade. I have the same problem and this is damn annoying. I have Net Core 3.1 project (Worker Service Template), Serilog 2.9.0. UseSerilog() is called on IHostBulder; ILogger is injected to every class with Autofac. Any mistake in structured logging formatting throws an error. How to make it silent? Can I use dev version of Serilog? How to set it up? |
Hi there!
This code throws because the SerilogLogger doesn't handle exceptions when MEL throws because of a missing log property value:
throws:
Given Serilog has a strong 'no-throw' on ILogger policy, it's a bit surprising when using a Serilog app logger that exceptions occur in badly-formed library log calls. Is it possible that this integration should protect against missing values and render them the same way Serilog does (i.e. as
{PropertyString}
?One impact of this is that it's not really possible to safely accept an
object[] args
to pass into log statement (as e.g. SerilogTimings does) as if the user doesn't pass the correct number of args, the logger throws.I believe MEL is acting badly here, as its ILogger throws when this occurs in client code so they aren't protecting against it.:
throws:
Thoughts?
The text was updated successfully, but these errors were encountered: