-
Notifications
You must be signed in to change notification settings - Fork 1.6k
CommonDelegatingErrorHandler: How to traverse exceptions in order to find a correct delegate #2288
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
Labels
backport 2.8.x (obsolete)
backport 2.9.x (obsolete)
ideal-for-user-contribution
An issue that would ideal for a user to get started with contributing.
Milestone
Comments
Hi @garyrussell, could you assign it to me? |
Hi, @breader124 ! It’s fine to take the issue just saying that you’re up. We can assign issues only to team members . thank you for considering to contribute! |
breader124
added a commit
to breader124/spring-kafka
that referenced
this issue
Jun 19, 2022
Fixes spring-projects#2288 Add possibility to deeply traverse cause chain in order to find proper delegate for handling thrown exception. Keep old way of cause chain traversing as default one. Cover new code with unit test.
PR created, please give it a look: #2310 |
breader124
added a commit
to breader124/spring-kafka
that referenced
this issue
Jun 19, 2022
Use BinaryExceptionClassifier while traversing cause chain to make it possible to classify throwables for handling based on inheritance etc.
breader124
added a commit
to breader124/spring-kafka
that referenced
this issue
Jun 25, 2022
garyrussell
pushed a commit
that referenced
this issue
Jul 7, 2022
Resolves #2288 GH-2288: Add option to deeply traverse exc chain Add possibility to deeply traverse cause chain in order to find proper delegate for handling thrown exception. Keep old way of cause chain traversing as default one. Cover new code with unit test. GH-2288: Make cause traversing more extensible Use BinaryExceptionClassifier while traversing cause chain to make it possible to classify throwables for handling based on inheritance etc. GH-2288: Remove custom BinaryExceptionClassifier Polish Javadocs.
garyrussell
pushed a commit
that referenced
this issue
Jul 7, 2022
Resolves #2288 GH-2288: Add option to deeply traverse exc chain Add possibility to deeply traverse cause chain in order to find proper delegate for handling thrown exception. Keep old way of cause chain traversing as default one. Cover new code with unit test. GH-2288: Make cause traversing more extensible Use BinaryExceptionClassifier while traversing cause chain to make it possible to classify throwables for handling based on inheritance etc. GH-2288: Remove custom BinaryExceptionClassifier Polish Javadocs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
backport 2.8.x (obsolete)
backport 2.9.x (obsolete)
ideal-for-user-contribution
An issue that would ideal for a user to get started with contributing.
Add an option to traverse the cause chain to find a delegate.
Discussed in #2283
Originally posted by amseager May 25, 2022
Currently, everything in this handler uses this private method:
As you can see, if we have
ListenerExecutionFailedException
, we'll get its cause and find an appropriate delegate.However, this wouldn't work in a lot of cases when we have our set of exceptions wrapped in something else, e.g. in
MessageConversionException
(I think it's the most popular case). And we cannot useMessageConversionException
as adelegates
map key since we want to have a different logic for each underlying exception (let's say we want customDefaultErrorHandler
forConstraintViolationException
with a fixed backoff and its own recoverer and the another one for any other exception withExponentialBackOff
without a recoverer at all - but both are wrapped in the sameMessageConversionException
).How to solve this problem? I don't want to write a custom DelegatingErrorHandler because I'll need to copy almost all the code from the
CommonDelegatingErrorHandler
.Previously, we had
ConditionalDelegatingErrorHandler
which hadhandle
method being public so it could've been ok to override it but now it's deprecated in favor ofCommonDelegatingErrorHandler
.The text was updated successfully, but these errors were encountered: