Hello people, do you use a Result type wrapper in the return types of your components? What if you use Clean Architecture. Would you use a Result type in Repositories, UseCases and ViewModels?

It is actually in the Google's guide to clean architecture as a part of the example, but I don't use in any of my mvvm/mvp projects as imo it just created additional "noise" and don't see much value added

I mostly use RxJava Single or do you mean something different?

I thought you mean this one?

I use it very often the pattern in the screenshot above. But instead of calling it

Resource

I name it

Event

. I also move the constructor fields from the base class to the subclasses. I don't use it with generic since I create one inner Event class per remote resource class. Maybe generics make it a clearer design.

I ended up using Kotlin Result for api calls. It's quite common for http request to fail, so a constant reminder that you have to handle the error is good. With exceptions it was too easy to skip/forget the handling. But doing it for everything might be an overengineering. As for google attempt, idk, having

Loading

in Result always felt like a very poor decision.

My error handling is either in rx onError (and it will actually crash if you don't implement it which will help not to forget) or in the catch block of a coroutine which is something you just have to know will throw an exception for multiple reasons and you need to catch it including your network errors. Now when you actually wanna add custom logic for failure like in the case when the request was successful but the response from the server is "failure" then having that Error in the Resource situation makes more sense.

I use mvvm + clean arch + RxJava in one of my recent project. I do handle this result type in repository.

Yes I was talking about a type like the Kotlin

Result

type or the

Resource

from Google ( but without loading etc).

no need for extra conversions. Repository gives you domain level

Result

with exceptions that are wrapped in some sort of domain

Error

. What's left is handling, probably in

ViewModel

and generating success/error state for the view.

Not always. There could be following scenario. We defined we could have for example a

GetUserMovieListUseCase

that combines data from 2 Repositories like:

UserRepository

and

MoviesRepository

where both of them return their data wrapped in some

Result

type. Then you have to check them both to combine them in a new `Result`type.

Yes, you might need to merge the errors. Frankly speaking, there are not that many errors that user can do anything about. Most of them will end up in a silent log to your monitoring tool, or a generic

Try again

button. So, at least in my case, the

when

statement stays pretty lean and doesn't bother me much.

Excesive use of

when

is fine. Is the way. Think of it as a discontinuous function in math.