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

Add shouldLog to better control logging spam #952

Closed
wants to merge 1 commit into from
Closed

Add shouldLog to better control logging spam #952

wants to merge 1 commit into from

Conversation

buttilda
Copy link
Contributor

@buttilda buttilda commented Feb 5, 2024

Currently, adding the problem-spring-web package will result in any exception that isn't explicitly handled to be logged in full (stack trace and all) and with no obvious way to stop it. While this may seem like a good idea, a common trope of handling expected errors is to throw a Problem or a ResponseStatusException after some validation step. For example:

@GetMapping("/route")
fun myRoute(@RequestHeader("X-Custom-Header") customHeader: String) {
  if (customHeader != "fixed-value") {
    throw ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid X-Custom-Header")
  }

  // happy path
}

Doing so while having problem-spring-web active will result in the hole stack-trace of ResponseStatusException to be logged.

This behaviour can be stopped by overriding the log(...) method in ProblemHandling but I'd argue that's not very obvious nor very clean. Thus, my proposed solution is adding a shouldLog(...) function which can then be overriden.

I chose to add the default behaviour of not logging ResponseStatusException or Problem as I believe those are pretty commonly thrown in situations where having the whole stack-trace printed isn't needed. Though I can agree with the argument that this would be a backwards incompatible change and therefore don't feel very strongly about it. Let me know and I can remove it and leave the implementation as return true; instead.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.

@buttilda buttilda changed the title Add shouldLog to better control logging spam Add shouldLog to better control logging spam Feb 5, 2024
@buttilda buttilda marked this pull request as ready for review February 5, 2024 08:33
@buttilda buttilda requested a review from a team as a code owner February 5, 2024 08:33
@buttilda buttilda closed this by deleting the head repository May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant