onFailure methods

[Artan1s]

Hi.

Could you please comment why have you chosen to write onFailure methods with Result<?, TFailure> as return type and not Result<TSuccess, TFailure> as in onSuccess?

I find it more difficult to compose that way and can't see any advantage of this choice.

[StefanMacke]

The idea was to focus on the TFailure type because in the case of a failure, TSuccess won't be present.

[Artan1s]

But the same logic can be applied to onSuccess methods, but they preserve TFailure in their return types. With onSuccess methods I can easily chain them in a single return statement without need to store some intermediate result like this:
Result<FinalSuccess, Error> doSmth() { return doOperation1() .onSuccess(operation1Success -> someSideEffect(operation1Success)) .map(operation1Success -> transformToFinalSuccess(operation1Success )); }
And i can add any other map, flatMap or onSuccess stuff in this chain. But when I need to have onFailure, then this chain breaks.

So I'm thinking about changing onFailure signatures to something more similar to onSuccess ones in my own version of Result 'pattern' implementation. And I'd like to know if you can give me some arguments against doing so.

[StefanMacke]

Actually, I can't think of any other argument at the moment! Feel free to send me a pull request! :-)