协程就是互相协作的程序,协程是结构化的。正因为 Kotlin 协程有这两个特点,这就导致它的异常处理机制与我们普通的程序完全不一样
在 Kotlin 协程当中,异常主要分为两大类,
- 一类是协程取消异常(CancellationException),
- 另一类是其他异常。
之所以要这么分类,是因为在 Kotlin 协程当中,这两种异常的处理方式是不一样的。下面将围绕这个展开介绍
面试官的题库,让一部分人先拿Offer!
为什么 cancel() 不起作用?
当协程任务被取消的时候,它的内部是会产生一个 CancellationException 的。而协程的结构化并发,最大的优势就在于:如果我们取消了父协程,子协程也会跟着被取消。但是我们也知道,很多初学者都会遇到一个问题,那就是协程无法被取消。
这里,主要涉及了三个场景,我们一个个来分析下
场景1 cancel() 不被响应
但通过运行的结果,我们可以看到协程并不会被取 消。这是为什么呢?
协程是互相协作的程序。因此,对于协程任务的取消,也是需要 互相协作的。协程外部取消,协程内部需要做出响应才行。
具体来说,我们可以在协程体中加入状态判断:
进一步分析代码段 1 无法取消的原因了:当我们调用 job.cancel() 以后,协程任务已经不是活跃状态了,但代码并没有把 isActive 作为循环条件,因此协程无法真正取消。
到这里,我们就可以总结出协程异常处理的第一准则:****协程的取消需要内部的配合。
场景2:结构被破坏
我们都知道,协程是结构化的,当我们取消父协程的时候,子协程也会跟着被取消
但在某些情况下,我们嵌套创建的子协程并不会跟随父协程一起取消,比如下面这个
以上代码中,我们创建了一个 fixedDispatcher,它是由两个线程的线程池实现的。接着,我们通过 launch 创建了三个协程,其中 parentJob 是父协程,随后我们等待 2000 毫秒,然后取消父协程。
不过,通过程序的运行结果,我们发现,虽然“子协程 1”当中使用了 while(isActive) 作为判断 条件,它仍然无法被取消。其实,这里的主要原因还是在注释 1 处,我们在创建子协程的时候,
使用了 launch(Job()){}。而这种创建方式,就打破了原有的协程结构。新的结构关系如下图所示
可以看到“子协程 1”已经不是 parentJob 的子协程了,而对应的,它的父 Job 是我们在 launch 当中传入的 Job() 对象。所以,在这种情况下,当我们调用 parentJob.cancel() 的时候,自然也就无法取消“子协程 1”了
其实这个时候,如果我们稍微改动一下上面的代码,不传入 Job(),程序就可以正常取消了。此时结构关系如下图所示
到这里,我们就可以总结出第二条准则了:不要轻易打破协程的父子结构!
场景 3:未正确处理 CancellationException
对于 Kotlin 提供的挂起函数,它们是可以自动响应协程的取消的,比如说,当我们把 Thread.sleep(500) 改为 delay(500) 以后,我们就不需要在 while 循环当中判断 isActive 了
我们可以在以上代码的基础上,增加一个 try-catch。
注释 1,在用 try-catch 包裹了 delay() 以后,我们就可以在输出结果中,看到“CatchCancellationException”,这就说明 delay() 确实可以自动响应协程的取消,并且产生CancellationException 异常
不过在这段代码中,我们把“throw e”这行代码注释掉,重新运行之后,程序就永远无法终止 了。这主要是因为,我们捕获了 CancellationException 以后没有重新抛出去,就导致子协程 无法正常取消
我们就可以总结出第三条准则了:捕获了 CancellationException 以后,要考 虑是否应该重新抛出来。
好,到这里,我们就通过协程取消异常的三个场景,总结了三条准则,来应对 CancellationException 这个特殊的异常。 那么接下来,我们再来看看如何在协程当中处理普通的异常。
为什么 try-catch 不起作用?
场景4:try-cath 范围不对
在 Kotlin 协程当中,try-catch 并非万能的。有时候,即使你用 try-catch 包裹了可能抛异常的代码,软件仍然会崩溃。
从运行结果这里,我们可以看到,try-catch 并没有成功捕获异常,程序等待了 100 毫秒 左右,最终还是崩溃了
这主要就是因为,当协程体当中的“1/0”执行的时候,我们的程序已经跳出 try-catch 的作用域了。
对于代码段 8 来说,我们可以挪动一下 try-catch 的位 置,比如说这样
我们就可以总结出第四条准则了:****不要用 try-catch 直接包裹 launch、 async
场景5:使用 SupervisorJob控制异常传播的范围。
SupervisorJob() 其实不是构造函数,它只是一个普通的顶层 函数。而这个方法返回的对象,是 Job 的子类
SupervisorJob 与 Job 最大的区别就在于,当它的子 Job 发生异常的时候,其他的子 Job 不会受到牵连,具体如下:
普通 Job,对于子 Job 出现异常时的应对策略。可以看到,由于 parentJob 是一个普通的 Job 对象,当 job1 发生异常之后,它会导致 parentJob 取消,进而导致 job2、job3 也受到牵连。
而这时候,如果我们把 parentJob 改为 SupervisorJob,job1 发生异常的的话,就不会影响到其他的 Job 了
我们就可以总结出第五条准则了:****灵活使用 SupervisorJob,控制异常传播的范围
不过并非所有情况下,我们都应该使用 SupervisorJob,有时候 Job 会更合适,这要结合实际场景分析。
场景6:CoroutineExceptionHandler
CoroutineExceptionHandler,它是 CoroutineContext 的元素之一,我们在创建协程的时候,可以指定对应的CoroutineExceptionHandler。
那么 CoroutineExceptionHandler 究竟适用于什么样的场景呢
在上面的代码中,我模拟了一个复杂的协程嵌套场景。对于这样的情况,我们其实很难一个个在每个协程体里面去写 try-catch。所以这时候,为了捕获到异常,我们就可以使用CoroutineExceptionHandler 了
我们定义了一个 CoroutineExceptionHandler,然后把它传入了 scope 当中,这样一来,我们就可以捕获其中所有的异常了
不过CoroutineExceptionHandler 需要定义在顶层,直接定义在发生异常的地方却不会生效!!!
上述代码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 作为补充。有了它,我们可以轻松捕获整个作用域内的所有异常。
1、本站所有资源均从互联网上收集整理而来,仅供学习交流之用,因此不包含技术服务请大家谅解!
2、本站不提供任何实质性的付费和支付资源,所有需要积分下载的资源均为网站运营赞助费用或者线下劳务费用!
3、本站所有资源仅用于学习及研究使用,您必须在下载后的24小时内删除所下载资源,切勿用于商业用途,否则由此引发的法律纠纷及连带责任本站和发布者概不承担!
4、本站站内提供的所有可下载资源,本站保证未做任何负面改动(不包含修复bug和完善功能等正面优化或二次开发),但本站不保证资源的准确性、安全性和完整性,用户下载后自行斟酌,我们以交流学习为目的,并不是所有的源码都100%无错或无bug!如有链接无法下载、失效或广告,请联系客服处理!
5、本站资源除标明原创外均来自网络整理,版权归原作者或本站特约原创作者所有,如侵犯到您的合法权益,请立即告知本站,本站将及时予与删除并致以最深的歉意!
6、如果您也有好的资源或教程,您可以投稿发布,成功分享后有站币奖励和额外收入!
7、如果您喜欢该资源,请支持官方正版资源,以得到更好的正版服务!
8、请您认真阅读上述内容,注册本站用户或下载本站资源即您同意上述内容!
原文链接:https://www.dandroid.cn/archives/22272,转载请注明出处。
评论0