<@U2E974ELT> I was thinking about the rx-java coro...
# coroutines
p
@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.
e
This result class is called
Try
in Scala (because of "try monad"). I cannot convince myself that it is useful enough to include it (and it is very easy to write if you need it). I will appreciate if you (or @gildor) share some real-life use-cases for such a class.
p
Well RxJava's onError quite common because composing is so easy. But when writing iterative code error throwing stuff is pain.
Copy code
kotlin
async {
  try {
    val user = userManager.user().await()
    try {
      val movies = movieManager.getMoviesForAge(user.age)
      val firstMovie = movies.first()
    
      } catch(e : IoException){
        showNetworkError()
      } catch(e : ...){
        show...
      }
  } catch(e: IoException){
    showNetworkError()
  } catch(e : HttpException){
    if(e.code==400) showNotSignedInException()
    else showNetworkError()
  }
}
Stuff like that
e
You can write one try {..} at the outermost level. Preferably in some kind of framework (your own wrapper for async, for example). I don't see any value in those nested trys.
p
Depending on where the exception happens they mean different things
e
I'd be really grateful for a chance to look at that in a larger context (a part of some real app). Do you know of any open source apps with this kind of logic?
g
@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.
when
block, especially with 3 cases, looks better then
try
with two
catch
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
.await()
that throws exception and
.awaitResult()
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
e
Thanks for detailed explanation. It would be interesting to hear your experience with the sample app.