时间戳

首页 > 解决方案 > 协程和改造，处理错误的最佳方式

android - 协程和改造，处理错误的最佳方式

问题描述

在阅读了这个问题How to deal with exception和这个 Medium Android Networking in 2019 — Retrofit with Kotlin's Coroutines 之后，我创建了我的解决方案，其中包括BaseService能够进行改造调用并将结果和异常转发到“链”：

API

@GET("...")
suspend fun fetchMyObject(): Response<List<MyObject>>

基本服务

protected suspend fun <T : Any> apiCall(call: suspend () -> Response<T>): Result<T> {
    val response: Response<T>
    try {
        response = call.invoke()
    } catch (t: Throwable) {
        return Result.Error(mapNetworkThrowable(t))
    }
    if (!response.isSuccessful) {
        return Result.Error...
    }
    return Result.Success(response.body()!!)
}

儿童服务

suspend fun fetchMyObject(): Result<List<MyObject>> {
    return apiCall(call = { api.fetchMyObject() })
}

回购

    suspend fun myObjectList(): List<MyObject> {
        return withContext(Dispatchers.IO) {
            when (val result = service.fetchMyObject()) {
                is Result.Success -> result.data
                is Result.Error -> throw result.exception
            }
        }
    }

注意：有时我们需要的不仅仅是抛出异常或一种类型的成功结果。为了处理这些情况，我们可以做到这一点：

sealed class SomeApiResult<out T : Any> {
    object Success : SomeApiResult<Unit>()
    object NoAccount : SomeApiResult<Unit>()
    sealed class Error(val exception: Exception) : SomeApiResult<Nothing>() {
        class Generic(exception: Exception) : Error(exception)
        class Error1(exception: Exception) : Error(exception)
        class Error2(exception: Exception) : Error(exception)
        class Error3(exception: Exception) : Error(exception)
    }
}

然后在我们的 ViewModel 中：

when (result: SomeApiResult) {
    is SomeApiResult.Success -> {...}
    is SomeApiResult.NoAccount -> {...}
    is SomeApiResult.Error.Error1 -> {...}
    is SomeApiResult.Error -> {/*all other*/...}
}

更多关于这种方法的信息在这里。

基础视图模型

protected suspend fun <T : Any> safeCall(call: suspend () -> T): T? {
    try {
        return call()
    } catch (e: Throwable) {
        parseError(e)
    }
    return null
}

子视图模型

fun fetchMyObjectList() {
    viewModelScope.launch {
        safeCall(call = {
            repo.myObjectList()
            //update ui, etc..
        })
    }
}

我认为ViewModel(or a BaseViewModel) 应该是处理异常的层，因为在这一层中存在 UI 决策逻辑，例如，如果我们只想显示一个 toast，忽略一种异常，调用另一个函数等......

你怎么看？

编辑：我用这个主题创建了一个媒体

标签： androidkotlinretrofit2kotlin-coroutineskotlin-android-extensions

解决方案

我认为 ViewModel（或 BaseViewModel）应该是处理异常的层，因为在这一层中存在 UI 决策逻辑，例如，如果我们只想显示一个 toast，忽略一种异常，调用另一个函数等。 ..

你怎么看？

当然，你是对的。ViewModel即使逻辑在Repository/中，协程也应该触发Service。这就是为什么谷歌已经创建了一个特殊的coroutineScope名为viewModelScope，否则它将是 "repositoryScope" 。协程还有一个很好的异常处理特性，称为CoroutineExceptionHandler. 这是事情变得更好的地方，因为您不必实现try{}catch{}块：

val coroutineExceptionHanlder = CoroutineExceptionHandler{_, throwable -> 
    throwable.printStackTrace()
    toastLiveData.value = showToastValueWhatever()
}

后来在ViewModel

coroutineScope.launch(Dispatchers.IO + coroutineExceptionHanlder){
      val data = serviceOrRepo.getData()
}

当然你仍然可以使用try/catch没有 的块CoroutineExceptionHandler，自由选择。

请注意，在 Retrofit 的情况下，您不需要Dispatchers.IO调度程序，因为 Retrofit 会为您执行此操作（从 Retrofit 2.6.0 开始）。

无论如何，我不能说这篇文章不好，但这不是最好的解决方案。如果您想遵循文章指南，您可能需要检查LiveData 上的转换。

编辑：您需要了解更多，协程并不安全。我的意思是，它们可能会导致内存泄漏，尤其是在整个 Android 生命周期中。您需要一种在Activity/Fragment不再存在时取消协程的方法。由于ViewModel具有（在/被销毁onCleared时调用），这意味着协程应该在其中一个中触发。也许这就是你应该在. 请注意，无需工作。ActivityFragmentViewModelviewModelScopecancelonCleared

一个简单的例子：

viewModelScope.launch(Dispatchers.IO) {
   val data = getDataSlowly()
   withContext(Dispatchers.MAIN) {
      showData();
   }
}

或没有viewModelScope：

val job = Job()
val coroutineScope = CoroutineContext(Dispatchers.MAIN + job)

fun fetchData() {
   coroutineScope.launch() {
   val data = getDataSlowly()
       withContext(Dispatchers.MAIN) {
          showData();
       }
   }
}

//later in the viewmodel:

override fun onCleared(){
  super.onCleared()
  job.cancel() //to prevent leaks
}

否则，您的Service/Repository会泄漏。另一个注意事项是在这种情况下不要 使用。GlobalScope

推荐阅读