知识图库
Java知识库
JDK线程池实现原理
Java中的强、软、弱、虚引用
深入拆解Java虚拟机
01 开篇词 | 为什么我们要学习Java虚拟机?
02 Java代码是怎么运行的?
03 Java的基本类型
04 Java虚拟机是如何加载Java类的?
05 JVM是如何执行方法调用的?(上)
06 JVM是如何执行方法调用的?(下)
7 JVM是如何处理异常的?
Java面试常见问题整理
Java面试常见问题-Java 基础篇
Java面试常见问题-Jvm篇
Java面试常见问题-并发篇
Android知识库
Kotlin编程第一课
1 开篇词 | 入门Kotlin有多容易,精通Kotlin就有多难
2 Kotlin基础语法:正式开启学习之旅
3 面向对象:理解Kotlin设计者的良苦用心
4 Kotlin原理:编译器在幕后干了哪些“好事”?
5 实战:构建一个Kotlin版本的四则运算计算器
6 object关键字:你到底有多少种用法?
7 扩展:你的能力边界到底在哪里?
8 高阶函数:为什么说函数是Kotlin的“一等公民”?
9 实战:用Kotlin写一个英语词频统计程序
10 加餐一 | 初识Kotlin函数式编程
11 委托:你为何总是被低估?
12 泛型:逆变or协变,傻傻分不清?
13 注解与反射:进阶必备技能
14 实战:用Kotlin实现一个网络请求框架KtHttp
15 加餐二 | 什么是“表达式思维”?
16 加餐三 | 什么是“不变性思维”?
17 加餐四 | 什么是“空安全思维”?
18 春节刷题计划(一)| 当Kotlin遇上LeetCode
19 春节刷题计划(二)| 一题三解,搞定版本号判断
20 春节刷题计划(三)| 一题双解,搞定求解方程
21 春节刷题计划(四)| 一题三解,搞定分式加减法
22 什么是“协程思维模型”?
23 如何启动协程?
24 挂起函数:Kotlin协程的核心
25 Job:协程也有生命周期吗?
26 Context:万物皆为Context?
27 实战:让KtHttp支持挂起函数
28 期中考试 | 用Kotlin实现图片处理程序
29 题目解答 | 期中考试版本参考实现
30 Channel:为什么说Channel是“热”的?
31 Flow:为什么说Flow是“冷”的?
32 select:到底是在选择什么?
33 并发:协程不需要处理同步吗?
34 异常:try-catch居然会不起作用?坑!
35 实战:让KtHttp支持Flow
36 答疑(一)| Java和Kotlin到底谁好谁坏?
37 集合操作符:你也会“看完就忘”吗?
38 协程源码的地图:如何读源码才不会迷失?
39 图解挂起函数:原来你就是个状态机?
40 加餐五 | 深入理解协程基础元素
41 launch的背后到底发生了什么?
42 Dispatchers是如何工作的?
43 CoroutineScope是如何管理协程的?
44 图解Channel:如何理解它的CSP通信模型?
45 图解Flow:原来你是只纸老虎?
46 Java Android开发者还会有未来吗?
47 Kotlin与Jetpack简直是天生一对!
48 用Kotlin写一个GitHub Trending App
49 结课测试 | “Kotlin编程第一课”100分试卷等你来挑战!
50 结束语 | 不忘初心
Android Framework 教程—基础篇
01 Ubuntu 使用快速入门
02 Make 构建工具入门
03 理解 Unicode UTF-8 UTF-16 UTF-32
04 Linux Shell 脚本编程入门1——核心基础语法
05 SeAndroid 使用极速上手
06 理解 C++ 的 Memory Order
07 AOSP 极速上手
08 系统开发工具推荐
09 添加 Product
运动相关知识
爱上跑步
01 开篇词 | 跑步,不那么简单的事儿
02 跑两步就喘了,是不是我不适合跑步?
03 正确的跑步姿势是什么样的?
04 为什么跑步要先热身?
05 怎样制定你的第一个10公里跑步计划?
06 快跑和慢跑,哪个更燃脂?
07 普通跑步者应该如何选择跑鞋?
08 买跑步装备,不要踩这些坑儿
09 跑步前到底应不应该吃东西?
10 跑步到底伤不伤膝盖?
11 参加了20场马拉松,我是如何准备的?
12 除了马拉松,还能参加哪些跑步赛事?
13 热点问题答疑 :跑完第二天浑身疼,还要不要继续跑?
健身房计划
[DeepSeek]减脂塑形计划
【DeepSeek】训练周期安排
每日餐饮热量控制
减脂期间食物推荐避坑指南
HarmonyOS知识库
其他知识类目
心理学相关
如何学点心理学——关于非专业人士学心理学的一点建议
投射性认同
-
+
首页
34 异常:try-catch居然会不起作用?坑!
这节课我们来学习Kotlin协程的异常处理。 其实到这里,我们就已经学完所有Kotlin协程的语法知识了。但在真正把Kotlin协程应用到生产环境之前,我们还需要掌握一个重要知识点,那就是异常处理。 比起Kotlin协程的语法知识点,协程的异常处理,其实更难掌握。在前面的课程中,我们已经了解到:协程就是互相协作的程序,协程是结构化的。正因为Kotlin协程有这两个特点,这就导致它的异常处理机制与我们普通的程序完全不一样。 换句话说:如果把Java里的那一套异常处理机制,照搬到Kotlin协程里来,你一定会四处碰壁。因为在普通的程序当中,你使用try-catch就能解决大部分的异常处理问题,但是在协程当中,根据不同的协程特性,它的异常处理策略是随之变化的。 我自己在工作中就踩过很多这方面的坑,遇到过各种匪夷所思的问题:协程无法取消、try-catch不起作用导致线上崩溃率突然大增、软件功能错乱却追踪不到任何异常信息,等等。说实话,Kotlin协程的普及率之所以不高,很大一部分原因也是因为它的异常处理机制太复杂了,稍有不慎就可能会掉坑里去。 那么今天这节课,我们就会来分析几个常见的协程代码模式,通过解决这些异常,我们可以总结出协程异常处理的6大准则。掌握了这些准则之后,你在以后遇到异常问题时,就能有所准备,也知道该怎么处理了。 ### 为什么cancel()不起作用? 在Kotlin协程当中,我们通常把异常分为两大类,一类是**取消异常**(CancellationException),另一类是**其他异常**。之所以要这么分类,是因为在Kotlin协程当中,这两种异常的处理方式是不一样的。或者说,在Kotlin协程所有的异常当中,我们需要把CancellationException单独拎出来,特殊对待。 要知道,当协程任务被取消的时候,它的内部是会产生一个CancellationException的。而协程的结构化并发,最大的优势就在于:如果我们取消了父协程,子协程也会跟着被取消。但是我们也知道,很多初学者都会遇到一个问题,那就是协程无法被取消。 这里,主要涉及了三个场景,我们一个个来分析下。 #### 场景1:cancel()不被响应 ```kotlin // 代码段1 fun main() = runBlocking { val job = launch(Dispatchers.Default) { var i = 0 while (true) { Thread.sleep(500L) i ++ println("i = $i") } } delay(2000L) job.cancel() job.join() println("End") } /* 输出结果 i = 1 i = 2 i = 3 i = 4 i = 5 // 永远停不下来 */ ``` 在上面的代码中,我们启动了一个协程,在这个协程的内部,我们一直对i进行自增。过了2000毫秒以后,我们调用了job.cancel()。但通过运行的结果,我们可以看到协程并不会被取消。这是为什么呢? 其实前面课程里我们就讲过,协程是互相协作的程序。因此,对于协程任务的取消,也是需要互相协作的。协程外部取消,协程内部需要做出响应才行。具体来说,我们可以在协程体中加入状态判断: ```kotlin // 代码段2 fun main() = runBlocking { val job = launch(Dispatchers.Default) { var i = 0 // 变化在这里 while (isActive) { Thread.sleep(500L) i ++ println("i = $i") } } delay(2000L) job.cancel() job.join() println("End") } /* 输出结果 i = 1 i = 2 i = 3 i = 4 i = 5 End */ ``` 在这段代码里,我们把while循环的条件改成了while (isActive),这就意味着,只有协程处于活跃状态的时候,才会继续执行循环体内部的代码。 这里,我们就可以进一步分析代码段1无法取消的原因了:当我们调用job.cancel()以后,协程任务已经不是活跃状态了,但代码并没有把isActive作为循环条件,因此协程无法真正取消。 所以到这里,我们就可以总结出协程异常处理的第一准则了:协程的取消需要内部的配合。 #### 场景2:结构被破坏 我们都知道,协程是结构化的,当我们取消父协程的时候,子协程也会跟着被取消。比如,我们在第16讲当中,就看到过这张图:  但在某些情况下,我们嵌套创建的子协程并不会跟随父协程一起取消,比如下面这个案例: ```kotlin // 代码段3 val fixedDispatcher = Executors.newFixedThreadPool(2) { Thread(it, "MyFixedThread").apply { isDaemon = false } }.asCoroutineDispatcher() fun main() = runBlocking { // 父协程 val parentJob = launch(fixedDispatcher) { // 1,注意这里 launch(Job()) { // 子协程1 var i = 0 while (isActive) { Thread.sleep(500L) i ++ println("First i = $i") } } launch { // 子协程2 var i = 0 while (isActive) { Thread.sleep(500L) i ++ println("Second i = $i") } } } delay(2000L) parentJob.cancel() parentJob.join() println("End") } /* 输出结果 First i = 1 Second i = 1 First i = 2 Second i = 2 Second i = 3 First i = 3 First i = 4 Second i = 4 End First i = 5 First i = 6 // 子协程1永远不会停下来 */ ``` 以上代码中,我们创建了一个fixedDispatcher,它是由两个线程的线程池实现的。接着,我们通过launch创建了三个协程,其中parentJob是父协程,随后我们等待2000毫秒,然后取消父协程。 不过,通过程序的运行结果,我们发现,虽然“子协程1”当中使用了while(isActive)作为判断条件,它也仍然无法被取消。其实,这里的主要原因还是在注释1处,我们在创建子协程的时候,使用了launch(Job()){}。而这种创建方式,就打破了原有的协程结构。 为了方便你理解,我画了一张图,描述它们之间的父子关系。  根据这张图,可以看到“子协程1”已经不是parentJob的子协程了,而对应的,它的父Job是我们在launch当中传入的Job()对象。所以,在这种情况下,当我们调用parentJob.cancel()的时候,自然也就无法取消“子协程1”了。 其实这个时候,如果我们稍微改动一下上面的代码,不传入Job(),程序就可以正常运行了。 ```kotlin // 代码段4 fun main() = runBlocking { val parentJob = launch(fixedDispatcher) { // 变化在这里 launch { var i = 0 while (isActive) { Thread.sleep(500L) i ++ println("First i = $i") } } launch { var i = 0 while (isActive) { Thread.sleep(500L) i ++ println("Second i = $i") } } } delay(2000L) parentJob.cancel() parentJob.join() println("End") } /* 输出结果 First i = 1 Second i = 1 First i = 2 Second i = 2 First i = 3 Second i = 3 First i = 4 Second i = 4 End */ ``` 在上面的代码中,parentJob与它内部的子协程1、子协程2之间是父子关系,因此它们两个都是会响应协程取消的事件的。这时候,它们之间的关系就变成了下图这样:  那么到这里,我们其实就可以总结出第二条准则了:**不要轻易打破协程的父子结构**! #### 场景3:未正确处理CancellationException 其实,对于Kotlin提供的挂起函数,它们是可以自动响应协程的取消的,比如说,当我们把Thread.sleep(500)改为delay(500)以后,我们就不需要在while循环当中判断isActive了。 ```kotlin // 代码段5 fun main() = runBlocking { val parentJob = launch(Dispatchers.Default) { launch { var i = 0 while (true) { // 变化在这里 delay(500L) i ++ println("First i = $i") } } launch { var i = 0 while (true) { // 变化在这里 delay(500L) i ++ println("Second i = $i") } } } delay(2000L) parentJob.cancel() parentJob.join() println("End") } /* 输出结果 First i = 1 Second i = 1 First i = 2 Second i = 2 First i = 3 Second i = 3 End */ ``` 实际上,对于delay()函数来说,它可以自动检测当前的协程是否已经被取消,如果已经被取消的话,它会抛出一个CancellationException,从而终止当前的协程。 为了证明这一点,我们可以在以上代码的基础上,增加一个try-catch。 ```kotlin // 代码段6 fun main() = runBlocking { val parentJob = launch(Dispatchers.Default) { launch { var i = 0 while (true) { // 1 try { delay(500L) } catch (e: CancellationException) { println("Catch CancellationException") // 2 throw e } i ++ println("First i = $i") } } launch { var i = 0 while (true) { delay(500L) i ++ println("Second i = $i") } } } delay(2000L) parentJob.cancel() parentJob.join() println("End") } /* 输出结果 First i = 1 Second i = 1 First i = 2 Second i = 2 First i = 3 Second i = 3 Second i = 4 Catch CancellationException End */ ``` 请看注释1,在用try-catch包裹了delay()以后,我们就可以在输出结果中,看到“Catch CancellationException”,这就说明delay()确实可以自动响应协程的取消,并且产生CancellationException异常。 不过,以上代码中,最重要的其实是注释2:“throw e”。当我们捕获到CancellationException以后,还要把它重新抛出去。而如果我们删去这行代码的话,子协程将同样无法被取消。 ```kotlin // 代码段7 fun main() = runBlocking { val parentJob = launch(Dispatchers.Default) { launch { var i = 0 while (true) { try { delay(500L) } catch (e: CancellationException) { println("Catch CancellationException") // 1,注意这里 // throw e } i ++ println("First i = $i") } } launch { var i = 0 while (true) { delay(500L) i ++ println("Second i = $i") } } } delay(2000L) parentJob.cancel() parentJob.join() println("End") } /* 输出结果 输出结果 First i = 1 Second i = 1 First i = 2 Second i = 2 First i = 3 Second i = 3 Second i = 4 .. First i = 342825 Catch CancellationException // 程序将永远无法终止 */ ``` 可见,在这段代码中,我们把“throw e”这行代码注释掉,重新运行之后,程序就永远无法终止了。这主要是因为,我们捕获了CancellationException以后没有重新抛出去,就导致子协程无法正常取消。 所以到这里,我们就可以总结出第三条准则了:捕获了CancellationException以后,要考虑是否应该重新抛出来。 >i 题外话:很多开发者喜欢在代码里捕获Exception这个父类,比如这样:catch(e: Exception){},这也是很危险的。平时写Demo为了方便这样写没问题,但在生产环境则应该禁止。 好,到这里,我们就通过协程取消异常的三个场景,总结了三条准则,来应对CancellationException这个特殊的异常。 那么接下来,我们再来看看如何在协程当中处理普通的异常。 ### 为什么try-catch不起作用? 如果你有Java经验,那你一定会习惯性地把try-catch当做是解决所有异常的手段。但是,在Kotlin协程当中,try-catch并非万能的。有时候,即使你用try-catch包裹了可能抛异常的代码,软件仍然会崩溃。比如下面这个例子: ```kotlin // 代码段8 fun main() = runBlocking { try { launch { delay(100L) 1 / 0 // 故意制造异常 } } catch (e: ArithmeticException) { println("Catch: $e") } delay(500L) println("End") } /* 输出结果: 崩溃 Exception in thread "main" ArithmeticException: / by zero */ ``` 在这段代码中,我们使用try-catch包裹了launch{},在协程体内部,我们制造了一个异常。不过从运行结果这里,我们可以看到,try-catch并没有成功捕获异常,程序等待了100毫秒左右,最终还是崩溃了。 类似的,如果我们把代码段8当中的launch换成async,结果也是差不多的: ```kotlin // 代码段9 fun main() = runBlocking { var deferred: Deferred? = null try { deferred = async { delay(100L) 1 / 0 } } catch (e: ArithmeticException) { println("Catch: $e") } deferred?.await() delay(500L) println("End") } /* 输出结果: 崩溃 Exception in thread "main" ArithmeticException: / by zero */ ``` 其实,对于这种try-catch失效的问题,如果你还记得在第14讲当中,我提到的launch、async的代码运行顺序的问题,那你就一定可以理解其中的原因。这主要就是因为,当协程体当中的“1/0”执行的时候,我们的程序已经跳出try-catch的作用域了。 当然,要解决这两个问题也很容易。对于代码段8来说,我们可以挪动一下try-catch的位置,比如说这样: ```kotlin // 代码段10 fun main() = runBlocking { launch { try { delay(100L) 1 / 0 // 故意制造异常 } catch (e: ArithmeticException) { println("Catch: $e") } } delay(500L) println("End") } /* 输出结果: Catch: java.lang.ArithmeticException: / by zero End */ ``` 也就是说,我们可以把try-catch挪到launch{} 协程体内部。这样一来,它就可以正常捕获到ArithmeticException这个异常了。 而对于代码段9的async的这个例子,我们其实有两种解决手段,其中一种跟上面的做法一样,我们把try-catch挪到了async{} 协程体内部,比如这样: ```kotlin // 代码段11 fun main() = runBlocking { var deferred: Deferred? = null deferred = async { try { delay(100L) 1 / 0 } catch (e: ArithmeticException) { println("Catch: $e") } } deferred?.await() delay(500L) println("End") } ``` OK,到这里,我们就可以总结出第四条准则了:不要用try-catch直接包裹launch、async。 接下来,我们再看看async的另外一种手段,其实这种方式网上有些博客也介绍过,我们可以使用try-catch包裹`deferred.await()`。让我们来看看是否可行: ```kotlin // 代码段12 fun main() = runBlocking { val deferred = async { delay(100L) 1 / 0 } try { deferred.await() } catch (e: ArithmeticException) { println("Catch: $e") } delay(500L) println("End") } /* 输出结果 Catch: java.lang.ArithmeticException: / by zero 崩溃: Exception in thread "main" ArithmeticException: / by zero */ ``` 那么,根据以上程序的运行结果可以看到,这样做其实是行不通的。如果你看过一些其他博客,甚至还有种说法是:await()如果不调用的话,async当中的异常甚至不会发生。我们再来试试看: ```kotlin // 代码段13 fun main() = runBlocking { val deferred = async { delay(100L) 1 / 0 } delay(500L) println("End") } /* 输出结果 崩溃: Exception in thread "main" ArithmeticException: / by zero */ ``` 可见,async当中产生异常,即使我们不调用await()同样是会导致程序崩溃的。那么,为什么会发生这样的情况?是不是我们忽略了什么? ### SupervisorJob 实际上,如果我们要使用try-catch包裹“deferred.await()”的话,还需要配合SupervisorJob一起使用。也就是说,借助SupervisorJob来改造代码段13的话,我们就可以实现“不调用await()就不会产生异常而崩溃”。 ```kotlin // 代码段14 fun main() = runBlocking { val scope = CoroutineScope(SupervisorJob()) scope.async { delay(100L) 1 / 0 } delay(500L) println("End") } /* 输出结果 End */ ``` 可以看到,当我们使用SupervisorJob创建一个scope以后,用scope.async{}启动协程后,只要不调用`deferred.await()`,程序就不会因为异常而崩溃。 所以同样的,我们也能用类似的办法来改造代码段12当中的逻辑: ```kotlin // 代码段15 fun main() = runBlocking { val scope = CoroutineScope(SupervisorJob()) // 变化在这里 val deferred = scope.async { delay(100L) 1 / 0 } try { deferred.await() } catch (e: ArithmeticException) { println("Catch: $e") } delay(500L) println("End") } /* 输出结果 Catch: java.lang.ArithmeticException: / by zero End */ ``` 在上面的代码中,我们仍然使用“scope.async {}”创建了协程,同时也用try-catch包裹`deferred.await()`,这样一来,这个异常就成功地被我们捕获了。 那么,SupervisorJob到底是何方神圣?让我们来看看它的源码定义: ```kotlin // 代码段16 public fun SupervisorJob(parent: Job? = null) : CompletableJob = SupervisorJobImpl(parent) public interface CompletableJob : Job { public fun complete(): Boolean public fun completeExceptionally(exception: Throwable): Boolean } ``` 根据以上代码,我们可以看到,SupervisorJob()其实不是构造函数,它只是一个普通的顶层函数。而这个方法返回的对象,是Job的子类。 SupervisorJob与Job最大的区别就在于,当它的子Job发生异常的时候,其他的子Job不会受到牵连。我这么说你可能会有点懵,下面我做了一个动图,来演示普通Job与SupervisorJob之间的差异。  这个是普通Job,对于子Job出现异常时的应对策略。可以看到,由于parentJob是一个普通的Job对象,当job1发生异常之后,它会导致parentJob取消,进而导致job2、job3也受到牵连。 而这时候,如果我们把parentJob改为SupervisorJob,job1发生异常的的话,就不会影响到其他的Job了。  所以到这里,我们就可以总结出第五条准则了:**灵活使用SupervisorJob,控制异常传播的范围**。 >i 提示:并非所有情况下,我们都应该使用SupervisorJob,有时候Job会更合适,这要结合实际场景分析。 好,到目前为止,我们就已经了解了try-catch和SupervisorJob这两种处理异常的手段。但是,由于协程是结构化的,当我们的协程任务出现复杂的层级时,这两种手段其实都无法很好的应对。所以这个时候,我们就需要CoroutineExceptionHandler出场了。 ### CoroutineExceptionHandler 对于CoroutineExceptionHandler,我们其实在第17讲里也简单地提到过。它是CoroutineContext的元素之一,我们在创建协程的时候,可以指定对应的CoroutineExceptionHandler。 那么CoroutineExceptionHandler究竟适用于什么样的场景呢?让我们来看一个例子: ```kotlin // 代码段17 fun main() = runBlocking { val scope = CoroutineScope(coroutineContext) scope.launch { async { delay(100L) } launch { delay(100L) launch { delay(100L) 1 / 0 // 故意制造异常 } } delay(100L) } delay(1000L) println("End") } /* 输出结果 Exception in thread "main" ArithmeticException: / by zero */ ``` 在上面的代码中,我模拟了一个复杂的协程嵌套场景。对于这样的情况,我们其实很难一个个在每个协程体里面去写try-catch。所以这时候,为了捕获到异常,我们就可以使用CoroutineExceptionHandler了。 ```kotlin // 代码段18 fun main() = runBlocking { val myExceptionHandler = CoroutineExceptionHandler { _, throwable -> println("Catch exception: $throwable") } // 注意这里 val scope = CoroutineScope(coroutineContext + Job() + myExceptionHandler) scope.launch { async { delay(100L) } launch { delay(100L) launch { delay(100L) 1 / 0 // 故意制造异常 } } delay(100L) } delay(1000L) println("End") } /* Catch exception: ArithmeticException: / by zero End */ ``` 以上代码中,我们定义了一个CoroutineExceptionHandler,然后把它传入了scope当中,这样一来,我们就可以捕获其中所有的异常了。 看到这里,你也许松了一口气:终于有了一个简单处理协程异常的方式了。不过,你也别高兴得太早,因为我曾经就踩过CoroutineExceptionHandler的一个坑,最终导致App功能大面积异常。 而出现这个问题的原因就是:CoroutineExceptionHandler不起作用了! ### 为什么CoroutineExceptionHandler不起作用? 为了模拟我当时的业务场景,我把代码段18稍作改动。 ```kotlin // 代码段19 fun main() = runBlocking { val myExceptionHandler = CoroutineExceptionHandler { _, throwable -> println("Catch exception: $throwable") } // 不再传入myExceptionHandler val scope = CoroutineScope(coroutineContext) scope.launch { async { delay(100L) } launch { delay(100L) // 变化在这里 launch(myExceptionHandler) { delay(100L) 1 / 0 } } delay(100L) } delay(1000L) println("End") } /* 输出结果 崩溃: Exception in thread "main" ArithmeticException: / by zero */ ``` 请你留意上面的注释,我们把自定义的myExceptionHandler,放到出现异常的launch那里传了进去。按理说,程序的执行结果是不会发生变化才对的。但实际上,myExceptionHandler并不会起作用,我们的异常不会被它捕获。 如果你对比代码段18和代码段19,你会发现,myExceptionHandler直接定义在发生异常的位置反而不生效,而定义在最顶层却可以生效!你说它的作用域是不是很古怪?  其实,出现这种现象的原因,就是因为:CoroutineExceptionHandler只在顶层的协程当中才会起作用。也就是说,当子协程当中出现异常以后,它们都会统一上报给顶层的父协程,然后顶层的父协程才会去调用CoroutineExceptionHandler,来处理对应的异常。 那么到这里,我们就可以总结出第六条准则了:使用CoroutineExceptionHandler处理复杂结构的协程异常,它仅在顶层协程中起作用。 ### 小结 至此,这节课的内容就接近尾声了,我们来做一个简单的总结。 在Kotlin协程当中,异常主要分为两大类,一类是协程取消异常(CancellationException),另一类是其他异常。为了处理这两大类问题,我们一共总结出了6大准则,这些我们都要牢记在心。  - 第一条准则:**协程的取消需要内部的配合**。 - 第二条准则:**不要轻易打破协程的父子结构**!这一点,其实不仅仅只是针对协程的取消异常,而是要贯穿于整个协程的使用过程中。我们知道,协程的优势在于结构化并发,它的许多特性都是建立在这个特性之上的,如果我们无意中打破了它的父子结构,就会导致协程无法按照预期执行。 - 第三条准则:**捕获了CancellationException以后,要考虑是否应该重新抛出来**。在协程体内部,协程是依赖于CancellationException来实现结构化取消的,有的时候我们出于某些目的需要捕获CancellationException,但捕获完以后,我们还需要思考是否需要将其重新抛出来。 - 第四条准则:**不要用try-catch直接包裹launch、async**。这一点是很多初学者会犯的错误,考虑到协程代码的执行顺序与普通程序不一样,我们直接使用try-catch包裹launch、async,是不会有任何效果的。 - 第五条准则:**灵活使用SupervisorJob,控制异常传播的范围**。SupervisorJob是一种特殊的Job,它可以控制异常的传播范围。普通的Job,它会因为子协程当中的异常而取消自身,而SupervisorJob则不会受到子协程异常的影响。在很多业务场景下,我们都不希望子协程影响到父协程,所以SupervisorJob的应用范围也非常广。比如说Android当中的viewModelScope,它就使用了SupervisorJob,这样一来,我们的App就不会因为某个子协程的异常导致整个应用的功能出现紊乱。 - 第六条准则:**使用CoroutineExceptionHandler处理复杂结构的协程异常,它仅在顶层协程中起作用**。我们都知道,传统的try-catch在协程当中并不能解决所有问题,尤其是在协程嵌套层级较深的情况下。这时候,Kotlin官方为我们提供了CoroutineExceptionHandler作为补充。有了它,我们可以轻松捕获整个作用域内的所有异常。 其实,这节课里我提到的这些案例,只是我平时工作中遇到的很小一部分。案例是讲不完的,在协程中处理异常,你将来肯定也会遇到千奇百怪的问题。但重要的是分析问题的思路,还有解决问题的手段。这节课我给你总结的6大准则呢,就是你将来遇到协程异常时,可以用的6种处理手段。 当我们遇到问题的时候,首先要分析是CancellationException导致的,还是其他异常导致的。接着我们就可以根据实际情况去思考,该用哪种处理手段了。 另外如果你足够细心的话,你会发现这节课总结出的6大准则,其实都跟协程的结构化并发有着密切联系。由于协程之间存在父子关系,因此它的异常处理也是遵循这一规律的。而协程的异常处理机制之所以这么复杂,也是因为它的结构化并发特性。 所以,除了这6大准则以外,我们还可以总结出一个核心理念:**因为协程是“结构化的”,所以异常传播也是“结构化的”。** 如果你能理解协程异常处理的核心理念,同时能够牢记前面的6大准则。我相信,将来不论你遇到什么样的古怪问题,你都可以分析出问题的根源,找到解决方案! ### 思考题 前面我们提到过,CoroutineExceptionHandler可以一次性捕获整个作用域内所有协程的异常。那么,我们是不是可以抛弃try-catch,只使用CoroutineExceptionHandler呢?为什么? 欢迎在留言区分享你的答案,也欢迎你把今天的内容分享给更多的朋友。
嘿手大叔
2024年10月30日 17:30
转发文档
收藏文档
上一篇
下一篇
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
分享
链接
类型
密码
更新密码