Skip stack trace capture in HttpProblem and guard ExceptionMapperBase against toProblem failures - #665
Open
phillip-kruger wants to merge 1 commit into
Conversation
… against toProblem failures HttpProblem is used as a structured error container, not for diagnostics. Overriding fillInStackTrace() avoids wasted CPU on every construction, especially for high-volume 4xx responses. ExceptionMapperBase.toResponse() now catches exceptions from toProblem() and handles null returns by falling back to a generic 500 response, ensuring the pipeline always produces valid application/problem+json.
gsmet
force-pushed
the
exception-pipeline-resilience
branch
from
August 5, 2026 08:04
42a7bfe to
8d3ab90
Compare
Collaborator
|
I like it. One consequence worth IMO calling out:
Maybe it's worth a short note in the README, something along the lines: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #669
Closes #670
HttpProblem extends RuntimeException but is used as a structured error container, not for diagnostics. Every construction was capturing a full stack trace - wasted CPU, especially for high-volume 4xx responses. Overriding fillInStackTrace() eliminates this overhead (the existing JMH benchmark can measure the improvement).
Separately, ExceptionMapperBase.toResponse() had no protection if a subclass's toProblem() threw an exception or returned null. The original mapped problem would be lost and the user would get an uncontrolled error instead of a proper application/problem+json response. Now the method catches exceptions and handles null by falling back to a generic 500 problem, logging the failure at ERROR level.