写点什么

发现不一样的 Kotlin 多方位处理协程的异常 (1),音视频时代你还不会 NDK 开发

用户头像
Android架构
关注
发布于: 刚刚

interface ProjectApi {


@GET("project/tree/json")


suspend fun loadProjectTree(): BaseResp<List<ProjectTree>>


@GET("project/tree/jsonError")


suspend fun loadProjectTreeError(): BaseResp<List<ProjectTree>>


}


Api 接口里面列出了两个接口,一个 loadProjectTree()作为能够请求成功的接口,loadProjectTreeError()则故意在 path 中多加了’Error’,模拟请求失败的状态。


具体调用:


suspend fun loadProjectTree() {


try {


val result = service.loadProjectTree()


val errorResult = service.loadProjectTreeError()


Log.d(TAG, "loadProjectTree: $result")


Log.d(TAG, "loadProjectTree errorResult: $errorResult")


} catch (e: Exception) {


Log.d(TAG, "loadProjectTree: Exception " + e.message)


e.printStackTrace()


}


}


我们看调用后的结果:


loadProjectTree: Exception HTTP 404 Not Found


由于故意将 loadProjectTreeError 接口中的 path 写错,执行流程理所当然的走进了 catch 里,报了 404 的错误。loadProjectTree 和 loadProjectTreeError 两个接口其实一个是成功,一个是失败,但当两个接口放在同一个 trycatch 块中,只要有一个失败,另外的请求即使是成功的,也不再执行。


如果我们想要彼此接口不影响,则需要为每个接口单独设立 try-catch 块。如下:


suspend fun loadProjectTree() {


try {


val errorResult = service.loadProjectTreeError()


Log.d(TAG, "loadProjectTree errorResult: $errorResult")


} catch (e: Exception) {


Log.d(TAG, "loadProjectTree: error Exception " + e.message)


e.printStackTrace()


}


try {


val result = service.loadProjectTree()


Log.d(TAG, "loadProjectTree: $result")


} catch (e: Exception) {


Log.d(TAG, "loadProjectTree: Exception " + e.message)


e.printStackTrace()


}


}


我们将 loadProjectTreeError 和 loadProjectTree 分别使用 try-catch 块进行异常捕获,运行结果也正如预期,接口请求互相不影响:


loadProjectTree: error Exception HTTP 404 Not Found


loadProjectTree: com.fuusy.common.network.BaseResp@57e153d


上述为一般状况下处理协程异常的方法,但是在某些情况下,try-catch 却也存在捕获不到异常的可能。

1.2 什么情况下 try-catch 会无效?

正常来说,try-catch 块中只有代码块存在异常,都将被捕获到 catch 中。但是协程中的异常却存在特殊情况。


例如在协程中开启一个失败的子协程,则无法捕获。还是以上面的接口举个例子:


fun loadProjectTree() {


viewModelScope.launch() {


try {


//子协程


launch {


//失败的接口


service.loadProjectTreeError()


}


} catch (e: Exception) {


e.printStackTrace()


}


}


}


在 try-catch 块中创建了一个子协程,调用了一个百分百会失败的接口,这个时候我们期望的是能将异常捕获至 catch 中,但是真正运行后却发现 App 崩溃退出了。这也验证了try-catch作用无效


至于try-catch为什么在协程中开启一个失败的子协程的情况下会失败?这就不得不提到一个新的知识点,协程的结构化并发

[](htt

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开:qq.cn.hn/FTe 免费领取
复制代码


ps://gitee.com/vip204888/java-p7)1.3 什么是协程的结构化并发?


在 kotlin 的协程中,全局的 GlobalScope 是一个作用域,每个协程自身也是一个作用域,新建的协程与它的父作用域存在一个级联的关系,也就是一个父子关系层次结构。而这级联关系主要在于:


  1. 父作用域的生命周期持续到所有子作用域执行完;

  2. 当结束父作用域结束时,同时结束它的各个子作用域;

  3. 子作用域未捕获到的异常将不会被重新抛出,而是一级一级向父作用域传递,这种异常传播将导致父父作用域失败,进而导致其子作用域的所有请求被取消。


上面的三点也就是协程结构化并发的特性。


了解了什么是协程的结构化并发,那我们就又回到try-catch为什么在协程中开启一个失败的子协程的情况下会失败?的问题上。很显然,上面第 3 点就是这个问题的答案,子协程中未捕获的异常不会被重新抛出,而是在父子层次结构中向上传播,这种异常传播将导致父Job失败。


在这种情况下,我们就应该使用一个新的处理异常的方法:CoroutineExceptionHandler


二、CoroutineExceptionHandler 全局捕获异常




除了try-catch外,协程处理异常的第二个方法是使用CoroutineExceptionHandler

2.1 CoroutineExceptionHandler 的介绍

首先我们来了解一下什么是CoroutineExceptionHandler


CoroutineExceptionHandler是用于全局“捕获所有”行为的最后一种机制。您无法在 CoroutineExceptionHandler 中从异常中恢复。当处理程序被调用时,协程已经完成了相应的异常。通常,该处理程序用于记录异常、显示某种错误消息、终止和/或重新启动应用程序。


这是官方文档中对CoroutineExceptionHandler的解释,起初时我对于这个解释是读不懂的,后面仔细想了想,CoroutineExceptionHandler作为一个全局捕获异常的方式,是由于协程结构化并发的特性的存在,子作用域的异常经过一级一级的传递,最后由CoroutineExceptionHandler进行处理。因为传递到CoroutineExceptionHandler时已经到达顶层作用域,这种情况下,子协程已经结束。也就是说在CoroutineExceptionHandler被调用时,所有子协程已经完成了相应的异常。

2.2 CoroutineExceptionHandler 的使用

首先,我们在 ViewModel 中创建了一个exceptionHandler


private val exceptionHandler = CoroutineExceptionHandler { _, exception ->


Log.d(TAG, "CoroutineExceptionHandler exception : ${exception.message}")


}


接着将exceptionHandler附加给viewModelScope。


fun loadProjectTree() {


viewModelScope.launch(exceptionHandler) {


//失败的接口


service.loadProjectTreeError()


}


}


根据协程的结构化并发的特性,当根协程通过launch{}启动时,异常将被传递给已附加的CoroutineExceptionHandler

2.3 CoroutineExceptionHandler 的不足

用户头像

Android架构

关注

还未添加个人签名 2021.10.31 加入

还未添加个人简介

评论

发布
暂无评论
发现不一样的Kotlin多方位处理协程的异常(1),音视频时代你还不会NDK开发