Vavr: Add Try.mapFailure(Function<Throwable, Throwable>)

[ronanM]

Sometimes it could be useful to map the failure to add more information, for example by chaining the exception.

Try<Item> itemTry = ....

itemTry.flatMap(item -> 
  doSomethingTry(item.quantity()) // This could fail, but without a useful information.
  .mapFailure(ex -> new Exception("Error while computing item with id: " + item.id(), ex))
)
...

Try<...> doSomethingTry(int quantity) {...}

For the moment it could be done using recoverWith(...) and a static mapFailure(...):

itemTry.flatMap(item -> 
  doSomethingTry(item.quantity()) // This could fail, but without a useful information.
  .recoverWith(mapFailure(ex -> new Exception("Error while computing item with id: " + item.id(), ex)))
)

public static <T> Function<? super Throwable, ? extends Try<? extends T>> 
mapFailure(Function<? super Throwable, ? extends Throwable> f) {
    return ex -> failure(f.apply(ex));
}

[danieldietrich]

Hi @ronanM,
thank you for your suggestion.
We could rather do it with recoverWith than introducing a new method:

itemTry.flatMap(item ->
        doSomethingTry(item.quantity()) // This could fail, but without a useful information.
        .recoverWith(ex -> Try.failure(new Exception("Error while computing item with id: " + item.id(), ex)))
);

Another equivalent solution is to use map and getOrElseThrow:

itemTry.mapTry(item ->
        doSomethingTry(item.quantity()) // This could fail, but without a useful information.
        .getOrElseThrow(ex -> new Exception("Error while computing item with id: " + item.id(), ex))
);

Maybe there are more solutions to the problem than I've shown above. I think we really do not need another method.

I will close the issue for now and also your PR.

Please don't worry when I close an issue. This is a step forward, not backward. We always learn s.th. new, me included!

[tinversenorm]

I'd like to reopen this for discussion. I think semantically mapFailure makes more sense and would be easier to read than recoverWith to add more information to a Try.failure. RecoverWith seems to be intended to recover a failure case and convert it to a success. The naming certainly indicates this.

[danieldietrich]

@tinversenorm you are right, it makes sense. It is already part of VAVR 1.0. There is a preview release of the control package: https://static.javadoc.io/io.vavr/vavr/1.0.0-alpha-2/io/vavr/control/Try.html#mapFailure(io.vavr.control.CheckedFunction)