Why is it allowed for @Retryable and @Recover to be used only within the same class?

[solomon-maeng]

Hello :) I am a developer using Spring-Retry.

Thank you for creating such a great library like Retry. As mentioned in the issue title, could you explain why @Retryable and @Recover are only allowed within the same class?

An explanation from an implementation perspective or dependency perspective would be appreciated.

[gaofengIt]

您好，我已经收到您的邮件，将尽快给您回复。

[yongsk0066]

I think the main reason for restricting @Retryable and @Recover to the same class lies in how Spring Retry implements its functionality using proxy-based AOP.

Spring Retry uses AOP proxies to intercept method calls annotated with @Retryable and apply the retry logic. For the proxy to handle both the retry and recovery logic effectively, it is essential to have @Retryable and @Recover within the same class. This allows the proxy to manage both methods and delegate the recovery process to the @Recover method when retries exhaust.
If @Recover were allowed in a separate class, it would complicate the proxy's ability to locate and invoke the appropriate recovery method, leading to a more complex implementation and potentially impacting performance.
Therefore, keeping @Retryable and @Recover together in the same class simplifies the AOP-based implementation, promotes better encapsulation, and maintains a more coherent design.

[artembilan]

See Javadoc for @Recover:

 * Annotation for a method invocation that is a recovery handler. A suitable recovery
 * handler has a first parameter of type Throwable (or a subtype of Throwable) and a
 * return value of the same type as the <code>@Retryable</code> method to recover from.
 * The Throwable first argument is optional (but a method without it will only be called
 * if no others match). Subsequent arguments are populated from the argument list of the
 * failed method in order.

The important part is:

and a return value of the same type as the @Retryable method

So, it is really crucial to have a logic in the same class to make an external call as transparent for this service as possible.

In the end it is not a big deal to delegate to some other service from that @Recover, but architecture for this feature is exactly like that: have all the retrying feature in the same service to follow a proper encapsulation principle.

Thanks, @yongsk0066 , for your answer!

Converting to discussion.