Clarify rethrowing of original exception in RetryTemplate

README.md

@@ -145,7 +145,7 @@ The decision to retry or not is actually delegated to a regular `RetryPolicy`, s
 
 ## Retry Policies
 
-Inside a `RetryTemplate` the decision to retry or fail in the execute method is determined by a `RetryPolicy` which is also a factory for the `RetryContext`. The `RetryTemplate` has the responsibility to use the current policy to create a `RetryContext` and pass that in to the `RetryCallback` at every attempt. After a callback fails the `RetryTemplate` has to make a call to the `RetryPolicy` to ask it to update its state (which will be stored in the `RetryContext`), and then it asks the policy if another attempt can be made. If another attempt cannot be made (e.g. a limit is reached or a timeout is detected) then the policy is also responsible for handling the exhausted state. Simple implementations will just throw `RetryExhaustedException` which will cause any enclosing transaction to be rolled back. You can also set a flag in the `RetryTemplate` to have it throw the original exception from the callback (i.e. from user code) instead. More sophisticated implementations might attempt to take some recovery action, in which case the transaction can remain intact.
+Inside a `RetryTemplate` the decision to retry or fail in the execute method is determined by a `RetryPolicy` which is also a factory for the `RetryContext`. The `RetryTemplate` has the responsibility to use the current policy to create a `RetryContext` and pass that in to the `RetryCallback` at every attempt. After a callback fails the `RetryTemplate` has to make a call to the `RetryPolicy` to ask it to update its state (which will be stored in the `RetryContext`), and then it asks the policy if another attempt can be made. If another attempt cannot be made (e.g. a limit is reached or a timeout is detected) then the policy is also responsible for identifying the exhausted state, but not for handling the exception. The `RetryTemplate` will throw the original exception, except in the stateful case, when no recover is available, in which case it throws `RetryExhaustedException`. You can also set a flag in the `RetryTemplate` to have it unconditionally throw the original exception from the callback (i.e. from user code) instead.
 
 > *Tip:*
 Failures are inherently either retryable or not - if the same exception is always going to be thrown from the business logic, it doesn't help to retry it. So don't retry on all exception types - try to focus on only those exceptions that you expect to be retryable. It's not usually harmful to the business logic to retry more aggressively, but it's wasteful because if a failure is deterministic there will be time spent retrying something that you know in advance is fatal.

src/main/java/org/springframework/retry/support/RetryTemplate.java

@@ -555,7 +555,7 @@ public class RetryTemplate implements RetryOperations {
 			return rethrow;
 		}
 		else {
-			throw new RetryException("Exception in batch process", throwable);
+			throw new RetryException("Exception in retry", throwable);
 		}
 	}