Allow specifying a more concrete Throwable type for retrying #3414
Conversation
Of course... 😂 |
Kover Report
|
| * Returns [Either] with the fallback value if the [Schedule] is exhausted, or the successful result of [action]. | ||
| */ | ||
| @JvmName("retryOrElseEitherReified") | ||
| public suspend inline fun <Input, Output, A, reified E : Throwable> Schedule<E, Output>.retryOrElseEither( |
There was a problem hiding this comment.
We should strive to keep the inline functions to be just small wrappers over the real functions (otherwise every change in the implementation breaks binary compatibility). My suggestion is to have a version which takes a KClass<E> as additional parameter (so you don't need the reified anymore), and then have a version which simply calls that function with E::class.
| * It will throw the last [E] if the [Schedule] is exhausted, and ignores the output of the [Schedule]. | ||
| */ | ||
| @JvmName("retryReified") | ||
| public suspend inline fun <A, reified E : Throwable> Schedule<E, *>.retry(action: suspend () -> A): A = |
There was a problem hiding this comment.
Nitpick: I think the reverse order of type arguments would look nicer on calls.
retry<ConnectionError, _> {
// do something
}
| @@ -412,6 +417,14 @@ public value class Schedule<in Input, out Output>(public val step: ScheduleStep< | |||
| public suspend fun <A> Schedule<Throwable, *>.retry(action: suspend () -> A): A = | |||
There was a problem hiding this comment.
Are you sure that the compiler is able to infer which version of retry you are calling? I'm a bit concerned about problems in resolving which one you want. Maybe we can change the other one to retryInstanceOf? This would follow the naming conventions in Kotlin (filterInstanceOf...)
There was a problem hiding this comment.
We should have tests, for this, but let's double check. I like to cover these API concerns in the tests as well, so we can also track it never breaks by accident.
|
Should we close this now that #3418 is merged? I don't want to step on your toes... |
|
Not stepping on my toes @serras 😘 Love collaborating together, the resulting Schedule is 😍 |
Small use-case I came across several times, and I stumbled across it again. This PR allows specifying concrete types for retrying. I.e.
TODO