-
Notifications
You must be signed in to change notification settings - Fork 524
Rethrow particular not-retryable exceptions #281
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is OK with me.
I don't like mixing "retryability" between the policy and the template; this should be in the policy. However, the The classifier checks for the actual class before traversing up the supers to find their classifications. |
Lines 353 to 359 in 0c1fa82
|
@garyrussell Thanks! I have changed the code according to your comments. |
@ttulka I don't understand why we need this at all; doesn't |
for (Class<? extends Throwable> type : rethrowExceptions) { | ||
policyMap.put(type, false); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is identical to the previous 3 lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is using rethrowExceptions
, the previous for
is using excludes
to iterate over.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right but why do we need rethrowExceptions
when we already have excludes
+ rethrow
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using rethrowExceptions
on Retryable
sets the noRecoveryForNotRetryable
flag of RetryTemplate, so the listed exceptions are not only not-retryable, but also directly rethrown (without recovery and wrapping).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, just set rethrow
alongside excludes
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sine 1.3.3 hasn't been built yet, maybe we should revert that commit until this is sorted out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done - maybe we should move this whole thing to the new 2.0 branch where we can overhaul the entire attribute list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not exactly happy about not getting anything in the next release, but as far as you guys decide on the API attributes, I would love to implement it if you want me to.
All in all, this feature is going to save me a lot of work!
Many thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand you are "not happy", but you realized that the previous commit did not satisfy all your needs and submitted this new PR, that does not use the new attribute from the previous commit.
It made no sense to us to release a version with a new attribute that would immediately become obsolete in the "next" release.
We are happy that you are willing to contribute, but we need to finalize a design that makes sense for the entire community, and provides minimal confusion for users with simpler use cases.
Thanks, again, for your contribution; we will continue to work this through.
@garyrussell Just using |
I think the premise of this request has been addressed after introducing this attribute to the
So, closing as duplication of: #264 |
Although
rethrow
helps a lot I have use-cases where I need exception handling to be even more flexible.rethrowExceptions
Example:
I want to retry server exceptions except for an authorization exception as this should be sent immediately and directly to the caller.