search

StefanMacke / ao-railway

Railway Oriented Programming in Java
MIT License
35 stars 15 forks source link

onFailure methods #4

Open Artan1s opened 6 years ago

Artan1s commented 6 years ago

Hi.

Could you please comment why have you chosen to write onFailuremethods 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 commented 6 years ago

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

Artan1s commented 6 years ago

But the same logic can be applied to onSuccess methods, but they preserve TFailurein 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 commented 6 years ago

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