【Kotlin 篇】多方位处理协程的异常，Android 高级工程师进阶学习—Android 热修复原理

\qquad\qquad 2.2 CoroutineExceptionHandler 的使用

\qquad\qquad 2.3 CoroutineExceptionHandler 的不足

\qquad 三、SupervisorScope+async

\qquad 四、结论

另外，网络请求异常封装可参考具体项目

一、try-catch 捕获异常

1.1 try-catch 基础使用

一般来说，处理异常可以使用 try-catch 块，在 try 中编写请求代码，catch 负责捕获异常。

以一个普通的请求为例：

Api 接口：

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,"loadProjectTreeerrorResult:$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()}}

我们将 loadProj

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

ectTreeError 和 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为什么在协程中开启一个失败的子协程的情况下会失败？这就不得不提到一个新的知识点，协程的结构化并发。

1.3 什么是协程的结构化并发？

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

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

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

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

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

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

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

二、CoroutineExceptionHandler 全局捕获异常

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

2.1 CoroutineExceptionHandler 的介绍

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