retry4j
retry4j copied to clipboard
Alternate API for building RetryConfig
Currently, the RetryConfigBuilder
has lot of options. Many of those options are exclusive and belong to logical groups. I was wondering whether we could simplify the API by having smaller group of builders; this might help users to browse the available options reasonably easier. Also please provide any alternate suggestions.
// **Exception retry config*
ExceptionRetryConfig exceptionRetryConfig = exceptionRetryConfigBuilder()
.failForAnyException()
.matchOnCause()
.build()
ExceptionRetryConfig exceptionRetryConfig = exceptionRetryConfigBuilder()
.matchExceptions(mex1, mex2)
.excludeExceptions(ex1, ex2)
.matchOnCause()
.build()
ExceptionRetryConfig exceptionRetryConfig = exceptionRetryConfigBuilder()
.matchExceptions(mex1, mex2)
.excludeExceptions(ex1, ex2)
.matchOnCause()
.onExceptionExecute(ex -> {})
.build()
// **Timing retry config: Option 1**
TimingRetryConfig timingRetryConfig = timingRetryConfigBuilder().maxTries(5).build()
TimingRetryConfig timingRetryConfig = timingRetryConfigBuilder().retryIndefinitely().build()
TimingRetryConfig timingRetryConfig = timingRetryConfigBuilder().delayBetweenTries(5, SECONDS).build()
TimingRetryConfig timingRetryConfig = timingRetryConfigBuilder().maxTries(5).build()
// **Timing retry config: Option 2**
TimingRetryConfig timingRetryConfig = TimingRetryConfig.maxTries(5)
TimingRetryConfig timingRetryConfig = TimingRetryConfig.retryIndefinitely()
TimingRetryConfig timingRetryConfig = TimingRetryConfig.delayBetweenTries(5, SECONDS)
// **Choosing a backoff strategy**
BackoffStrategy backoffStrategy = BackoffStrategy.FIBONACCI
BackoffStrategy backoffStrategy = BackoffStrategy.fixedBackoff5Tries10Sec()
// **Building the complete immutable RetryConfig**
RetryConfig retryConfig = retryConfigBuilder()
.exceptionRetryConfig(exceptionRetryConfig)
.retryOnReturnValue(value)
.timingRetryConfig(timingRetryConfig)
.backoffStrategy(BackoffStrategy.XYZ)
.build();
I agree with the issue, the config builder definitely has grown to have a lot of options with some being required, some being optional, some being mutually exclusive, etc. Until now I've tried to get around that using the builder validation to indicate when someone tries to build a config in an invalid state and via examples/documentation. I'd be ok trying out some form of what you laid out above with sub builders... do you want to try prototyping something so we can see a concrete example and see how it feels?
Also it might be worth checking out some other libraries to see how they handle streamlining their configuration/setup... it's possible we could get some ideas from what others have done. I have a list of other Java retry libraries at the bottom of the README you can use to start with if you're interested in that: https://github.com/elennick/retry4j#other-notes
I will make an attempt / POC this week