Reactive Programming with Reactor 3
Open Source Your Knowledge, Become a Contributor
Technology knowledge has to be shared and made accessible for free. Join the movement.
Error
Description
Reactor ships with several operators that can be used to deal with errors: propagate errors
but also recover from it (eg. by falling back to a different sequence or by retrying a new
Subscription
).
Practice
In the first example, we will return a Mono
containing default user Saul when an error occurs in
the original Mono
, using the method onErrorReturn
. If you want, you can even limit that
fallback to the IllegalStateException
class. Use the User#SAUL
constant.
Let's try the same thing with Flux
. In this case, we don't just want a single fallback
value, but a totally separate sequence (think getting stale data from a cache). This can
be achieved with onErrorResume
, which falls back to a Publisher<T>
.
Emit bothUser#SAUL
and User#JESSE
whenever there is an error in the original FLux
:
Dealing with checked exceptions is a bit more complicated. Whenever some code that throws
checked exceptions is used in an operator (eg. the transformation function of a map
), you
will need to deal with it. The most straightforward way is to make a more complex lambda with
a try-catch
block that will transform the checked exception into a RuntimeException
that
can be signalled downstream.
There is a Exceptions#propagate
utility that will wrap a checked exception into a special
runtime exception that can be automatically unwrapped by Reactor subscribers and StepVerifier
:
this avoids seeing an irrelevant RuntimeException
in the stacktrace.
Try to use that on the capitalizeMany
method within a map
: you'll need to catch a
GetOutOfHereException
, which is checked, but the corresponding test still expects the
GetOutOfHereException
directly.