发现不一样的Kotlin多方位处理协程的异常

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

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。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以添加下面V无偿领取！（备注Android）

架构师筑基包括哪些内容

我花了将近半个月时间将：深入 Java 泛型.、注解深入浅出、并发编程.、数据传输与序列化、Java 虚拟机原理、反射与类加载、高效 IO、Kotlin项目实战等等Android架构师筑基必备技能整合成了一套系统知识笔记PDF，相信看完这份文档，你将会对这些Android架构师筑基必备技能有着更深入、更系统的理解。

由于文档内容过多，为了避免影响到大家的阅读体验，在此只以截图展示部分内容，详细完整版的【架构师筑基必备技能】文档领取方式：点赞+关注，然后私信关键词 【666】即可获得免费领取方式！或者 可以查看我的【Github】

注：资料与上面思维导图一起看会更容易学习哦！每个点每个细节分支，都有对应的目录内容与知识点！

部分内容，详细完整版的【架构师筑基必备技能】文档领取方式：点赞+关注，然后私信关键词 【666】即可获得免费领取方式！或者 可以查看我的【Github】**

注：资料与上面思维导图一起看会更容易学习哦！每个点每个细节分支，都有对应的目录内容与知识点！

[外链图片转存中…(img-4g3BsBI1-1710903111897)]
[外链图片转存中…(img-waSsZCrd-1710903111897)]
这份资料就包含了所有Android初级架构师所需的所有知识！需要的可以在我的GIthub里面去查看！