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

stateless retry always throws original exception on exhaustion #40

Closed
zyro23 opened this issue Apr 11, 2016 · 4 comments
Closed

stateless retry always throws original exception on exhaustion #40

zyro23 opened this issue Apr 11, 2016 · 4 comments

Comments

@zyro23
Copy link

zyro23 commented Apr 11, 2016

this is maybe more a question than a real issue but i would like to know what is the expected behavior.

the readme states that

Simple implementations will just throw RetryExhaustedException which will cause any enclosing transaction to be rolled back

but for a stateless retry, that is not the behavior i am seeing (always original exception thrown).

handleRetryExhausted is invoked correctly, with state being null (ok, i guess, because the retry is stateless). but then, it looks like always the original exception is thrown back to the user, never wrapped in an ExhaustedRetryException. that is because thrown() is not invoked but instead just throw wrapIfNecessary(context.getLastThrowable()); (https://github.com/spring-projects/spring-retry/blob/master/src/main/java/org/springframework/retry/support/RetryTemplate.java#L467)

thanks for clarification!

@garyrussell
Copy link
Contributor

Looks like an error in the README - the Javadoc just above the line you linked to defines the behavior you observe.

@zyro23
Copy link
Author

zyro23 commented Apr 12, 2016

ah ok, thanks :)
but then currently no way to make a stateless retry throw an ExhaustedRetryException by default, right?
in some cases it would be useful to be able to distinguish that cause from the original exceptions - but if thats really needed the wrapping can be handled manually in a recoverer as well, i guess...

@garyrussell
Copy link
Contributor

Yeah, I agree it's a bit inconsistent but, as you say, you can do it via a simple recoverer.

@dsyer
Copy link
Member

dsyer commented Aug 23, 2016

Thanks, fixed in c8f2d07.

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

No branches or pull requests

3 participants