Match against exception causes in @Retryable and RetryPolicy
Prior to this commit, our @Retryable support as well as a RetryPolicy
created by the RetryPolicy.Builder only matched against top-level
exceptions when filtering included/excluded exceptions thrown by a
@Retryable method or Retryable operation.
With this commit, we now match against not only top-level exceptions
but also nested causes within those top-level exceptions. This is
achieved via the new ExceptionTypeFilter.match(Throwable, boolean)
support.
See gh-35592
Closes gh-35583
@ -26,8 +26,10 @@ public void sendNotification() {
@@ -26,8 +26,10 @@ public void sendNotification() {
By default, the method invocation will be retried for any exception thrown: with at most 3
retry attempts after an initial failure, and a delay of 1 second between attempts.
This can be specifically adapted for every method if necessary – for example, by narrowing
the exceptions to retry:
This can be specifically adapted for every method if necessary — for example, by narrowing
the exceptions to retry via the `includes` and `excludes` attributes. The supplied
exception types will be matched against an exception thrown by a failed invocation as well
as nested causes.
[source,java,indent=0,subs="verbatim,quotes"]
----
@ -182,7 +184,8 @@ If you only need to customize the number of retry attempts, you can use the
@@ -182,7 +184,8 @@ If you only need to customize the number of retry attempts, you can use the
If you need to narrow the types of exceptions to retry, that can be achieved via the
`includes()` and `excludes()` builder methods.
`includes()` and `excludes()` builder methods. The supplied exception types will be
matched against an exception thrown by a failed operation as well as nested causes.
[source,java,indent=0,subs="verbatim,quotes"]
----
@ -204,7 +207,7 @@ If you need to narrow the types of exceptions to retry, that can be achieved via
@@ -204,7 +207,7 @@ If you need to narrow the types of exceptions to retry, that can be achieved via
For advanced use cases, you can specify a custom `Predicate<Throwable>` via the
`predicate()` method in the `RetryPolicy.Builder`, and the predicate will be used to
determine whether to retry a failed operation based on a given `Throwable` – for example,
by checking the cause or the message of the `Throwable`.
by checking the message of the `Throwable`.
Custom predicates can be combined with `includes` and `excludes`; however, custom
predicates will always be applied after `includes` and `excludes` have been applied.