<@U2E974ELT> I was thinking about the rx-java coro...
# coroutines
@elizarov I was thinking about the rx-java coroutine .await. I think it might make sense to create a wrapping class that encapsulates the error / sucess. 8 replies @elizarov This approach is mostly experimental for me, I’m trying to understand what is the most convenient way to use it. I had 3 main goals with Result sealed class/monad: 1. 3 types of answer: HTTP success, HTTP error and other exceptions. Because Retrofit.Call has such separation (but HTTP success and error has the same additional wrapper) 2. Easy to write extension functions for such class then implement a lot of coroutine implementations. I have getOrNull, getOrThrow and getOrDefault. For some real cases in UI it’s just allow to write less code, because sometimes you don’t care if http (or network) error happened, and you don’t want to handle exception, especially inside loops 3.
block, especially with 3 cases, looks better then
with two
blocks %) Actually I’m not evangelist of this approach. I’m still not sure what will be more useful in the real app and how good this practice. And it’s the reason why I've implement
that throws exception and
with Result class. I’m writing Android sample app that uses coroutines for different async operations to show some examples of usage coroutines in Android and understand for myself how to better use it