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 an official mean of identifying traceback exceptions #1953
Comments
Given that composite exceptions overlap with checkpoints in the sense that both rely on suppressed exceptions, I think there should be a first-class way to separate actual errors from checkpoint ones, for exception handling purposes (e.g. spring-projects/spring-framework#23827) as opposed to extra information for debugging purposes. I'd argue that |
Additional TODO:
|
@rstoyanchev I wonder if the suppressed exception implementation of I'm not sure how to best communicate about that in the javadoc, seems that attempting to mention |
What do you have in mind for revisiting the The checkpoint is there for a reason but I want to make a distinction between value from the perspective of exception handling vs for value for debugging/reporting purposes. If I make calls to remote services that return errors to the effect of some entity does not exist, or the input incomplete/invalid, I may choose to handle those errors in some way like returning a specific status, or perhaps notifying something/someone. Checkpoint exceptions on the other hand have no role to play in such handling. The reporter under the above issue makes it clear they do not want to see the checkpoint exceptions in the In addition, the information value of the checkpoint exception is more clearly suited for server side logging/reporting. It is arguably not something that should leak out in the body of an error response. It likely contains information that was not meant for external consumption. As for the Javadoc it might be more natural to mention how to extract the composite exception (i.e. a pointer to |
@rstoyanchev maybe something more like a |
@rstoyanchev I added |
Motivation
There is no good way to detect if a
Throwable
is a traceback, which could be useful in cases where eg. such a traceback is added to aCompositeException
.Desired solution
Add an official API to check if a
Throwable
is a traceback.Considered alternatives
The
OnAssemblyException
being package-private means thatinstanceof
cannot be used. Relying ongetClass().getCanonicalName()
from within user code is an alternative, but less than ideal compared to doing that from core codebase.Another alternative would be to have a parameter to
Exceptions.unwrap
to chose wether or not to filter out tracebacks, or having it always filter out tracebacks.Additional context
checkpoint
operator adds the traceback as a suppressed exception.CompositeException
uses the same mechanism to gather its composites, so the traceback appears in the list when unwrapping the composite.The text was updated successfully, but these errors were encountered: