Skip to content
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

Default ExceptionHandlerMiddleware should have an option to suppress log output #46962

Closed
1 task done
jez9999 opened this issue Mar 1, 2023 · 4 comments
Closed
1 task done
Labels
area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlesware feature-diagnostics Diagnostic middleware and pages (except EF diagnostics)

Comments

@jez9999
Copy link

jez9999 commented Mar 1, 2023

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

This is has been reported before here: #42950

The suggested resolution was to set log level to None for Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware. Whilst this kind of works, I think it's a pretty terrible solution.

First, it semantically looks - from a glance at log levels - like you don't want exceptions logged. And this is just because you (in your custom exception handling middleware, registered in app.UseExceptionHandler) are logging exceptions in a way you want, instead of leaving it to ExceptionHandlerMiddleware.

Second, if some third-party exception handling middleware is registered in the pipeline, it can't control the log levels, so you'll have to manually suppress ExceptionHandlerMiddleware's logs via the log levels. This is messy.

Expected Behavior

Middleware registered via app.UseExceptionHandler() should have a way to completely suppress error logging made by ExceptionHandlerMiddleware, and considering a custom exception handler is quite likely to make its own logs, that suppression should maybe even be the default. Nevertheless, it should be an option.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

@Tratcher
Copy link
Member

Tratcher commented Mar 1, 2023

This may be addressed by #46280. That adds a way to treat specific exceptions as known and reduce their log impact. Unknown/unexpected exceptions would continue to be logged as errors.

@Tratcher Tratcher added area-runtime feature-diagnostics Diagnostic middleware and pages (except EF diagnostics) labels Mar 1, 2023
@stevendarby
Copy link

This may be addressed by #46280. That adds a way to treat specific exceptions as known and reduce their log impact. Unknown/unexpected exceptions would continue to be logged as errors.

Great, and actually one of the proposed solutions in my closed issue.

@adityamandaleeka
Copy link
Member

Cool, sounds like this is a duplicate of #46280 so I'll close this one.

@jez9999
Copy link
Author

jez9999 commented Mar 2, 2023

Cool, sounds like this is a duplicate of #46280 so I'll close this one.

Could someone confirm that that bug's solution will allow my code to put in place an error handler that handles all exceptions instead of the default handler?

@ghost ghost locked as resolved and limited conversation to collaborators Apr 1, 2023
@amcasey amcasey added area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlesware and removed area-runtime labels Jun 2, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-middleware Includes: URL rewrite, redirect, response cache/compression, session, and other general middlesware feature-diagnostics Diagnostic middleware and pages (except EF diagnostics)
Projects
None yet
Development

No branches or pull requests

5 participants