Provide alternative to `execute(Retryable)` which avoids `RetryException` in favor of rethrowing the last original `RuntimeException`

[wimdeblauwe]

Not really an issue, but I was very courius to know why RetryException is an Exception, but not a RuntimeException. What was the design rationale on this, knowing that normally Spring uses unchecked exceptions?

[jhoeller]

The rationale here is that RetryException is not meant to ever be propagated higher up; it's rather always meant to be handled by the immediate RetryTemplate caller. If you propagate anything higher up, it's usually the cause of the RetryException (the last exception thrown by the callback code, as we do for @Retryable methods) or possibly a custom exception that indicates the retry attempts.

That said, RetryTemplate does not make the common scenario very convenient at the moment since it requires an exception cast on rethrowing the last original exception. We could add a R invoke(Supplier<R> retryable) style method which just deals with unchecked exceptions and always propagates the last exception thrown from the supplier. That way, you'd never even see the RetryException, analogous to @Retryable method invocations. Would that help for your programmatic use cases? If so, we could repurpose this issue into a corresponding enhancement request.

[wimdeblauwe]

That does sound interesting indeed. But is it possible given that the cause of a RetryException is a Throwable, not a RuntimeException?

Next to that, I think it would be great to update the Javadoc of the execute method to indicate that the RetryException should not be propagated up the chain, but most likely, you want to get the cause and propagate that one to the caller instead.

[jhoeller]

Given the Supplier signature of the callback (which does not declare a checked exception), we effectively know that the resulting cause can only be an unchecked exception. The way we usually rethrow this in the framework is ReflectionUtils.rethrowRuntimeException (which turns any unexpected checked exception into an `UndeclaredThrowableException´ - but that this is not expected with proper contextual usage to begin with), so my local PoC also uses that.

Since I see that as a pragmatic programmatic variant for a common case, I'll schedule it for inclusion in 7.0.3. It effectively provides a direct replacement for @Retryable with the same exception rules, so it's also addressing convenient programmatic usage as an immediate alternative to the annotation variant. I'll repurpose this issue for it then.