抽丝剥茧聊Kotlin协程之协程异常处理机制分析

Posted 2022-02-01 冬天的毛毛雨

作者：字节小站

1. 前言

如果你是第一次听说有人把异常处理和事件分发联系在一起，相信你会跟我第一次接触协程异常处理机制时一样，一脸懵逼。别说在座的各位有不少android老司机，就算是Android萌新，也应该知道，异常处理不就是try catch这么简单的事么，怎么能和复杂的事件分发机制扯上关系？别不信还真扯的上关系。

如果你已经接触协程知识有段时间，并且知道协程的异常处理机制和我们以往了解的异常处理机制不一样，但是又没能完全它的原理，我会一步一步带你搞清楚这是怎么回事。

如果你对协程异常处理机制了然于胸，那么恭喜你，我觉得在当前时间点，你已经超越了大部分的人。希望这篇文章可以给处于各个不同阶段的朋友，不同程度的帮助。

当然，本文并不会详细介绍事件分发。Android的View体系和协程的结构化并发一样，它们对应的数据结构都是tree。View的事件分发和协程的Cancel传播机制很相似，使用的都是树的深度遍历算法。事件分发可参考Android事件分发机制分析。

2. 异常捕获

1. Kotlin中的异常捕获和Java一样，用try catch就能捕获住异常。我们来看一个简单的例子👇。通过try catch捕获异常。结果打印"caught null pointer exception"。

2. 启动一个协程👇。在协程体内捕获异常，结果与预期一样，打印“caught null pointer exception”。

3. 假设有个第三方提供的方法thirdApi。thirdApi方法启动了一个协程而且没有捕获异常👇。结果导致程序崩溃。

4. 开始一脸懵逼 要解决上述崩溃问题，我们的第一反应是在调用thirdApi的地方加上try catch👇，so easy嘛！运行代码，傻眼了，程序照样崩溃。try catch包住CoroutineScope.launch无法捕获住异常？

5. 虽然不明白上述代码为什么捕获不住异常，但是我知道协程有CoroutineExceptionHandler可以处理异常，👇如下试试看能否捕获住异常？结果打印"caught null pointer exception"。

6. 继续一脸懵逼 👇如果把exceptionHandler放到第二个launch方法中，竟然又捕获不住异常，程序又崩溃了。

7. 继续一脸懵逼 如果用coroutineScope包住第二个launch方法，情况又不一样了👇，结果打印“caught exception in try catch exception null pointer exception”。异常被try catch捕获住，而不是被exceptionHandler捕获住。

8. 继续一脸懵逼 如果用supervisorScope代替coroutineScope，情况又不一样了👇，结果打印“caught exception in handler null pointer exception”。被exceptionHandler捕获住了。

9. 在7的代码基础上，如果把try catch去掉，在外层的launch方法中增加outerExceptionHandler参数👇。打印结果为“caught exception in outer handler null pointer exception”。异常被outerExceptionHandler捕获住了。

10. 继续一脸懵逼 在9的代码基础上把coroutineScope替换成supervisorScope👇。打印结果为“caught exception in inner handler null pointer exception”。异常被innerExceptionHandler捕获住了。

上面10个场景，不管你是初学者还是协程老手，相信你已经晕头转向了。一个简单的异常处理，到协程里面怎么就变幻出这么多种场景，而且结果都不一样。如果不掌握协程异常处理逻辑，真不敢在项目中上协程。否则项目怎么崩溃的都不知道。

别纠结上述场景了，那只不过是我罗列出的10个场景，从理论上讲，这些场景可以72变，变化出无数种场景。但是万变不离其宗，只有掌握了原理，方能应对自如。

3. 异常处理原理

在聊聊Job和SupervisorJob的区别一文中我简单介绍了异常处理原理。要想理解异常处理原理也必须先了解结构化并发，可以参考Kotlin协程是如何建立结构化并发的？

异常的处理逻辑可以用职场的例子解释。假设职场的潜规则是，任何员工出错了，首要是要向上级报告，如果上级愿意处理你的错误，那员工就不用管了，如果上级将问题打回给员工，那错误就得由员工自己处理。

以下图为例讲解异常处理机制，Job5处发生异常（此处指非CancellationException）。

1. Job5首先会把异常传递给Job2处理。Job2有两种选择，选择一是不处理该异常，将异常打回给Job5，Job5调用handleJobException方法。选择二是Job2选择处理该异常，那么异常就传递给Job2了，Job5再也没有机会处理异常。
2. Job2处理异常的逻辑同Job5，首先会把异常传递给Job0。Job0同样有两种选择，打回交由Job2处理，调用Job2的handleJobException方法或者由Job0处理。
3. 协程中根Job是不会处理异常的，它会将异常打回交由子Job处理。本例子中Job0会把异常交由Job2处理。
4. Job handleJobException处理异常的逻辑是，首先判断协程的context是否设置过CoroutineExceptionHandler，如果有则交由CoroutineExceptionHandler处理异常。如果没设置过则会交由AndroidExceptionPreHandler处理。

有几个需要注意的点

1. CancellationException传播给父Job，一定会被打回。换而言之，它不会影响父Job。
2. SupervisorJob和supervisorScope一样会把异常打回给子Job处理，它们都可以把异常掐死在内部，不往外传播。
3. coroutineScope和withContext可以把协程的异常rethrow，也就是可以在他们外层加try catch捕获。

4. 最后

最后点下题吧。事件分发的Down事件是树的先序遍历算法(根右左)。而非Down事件(如Move、Up等事件)是根据TouchTarget生成的事件链表做的链表遍历。协程也是类似，cancel事件，先取消自己和子协程，是根据先序遍历(根左右)，然后再取消父协程(父协程同样是先序遍历取消)。异常处理则是根据子节点->父节点的链表遍历请求处理异常。说是一母同胞实在是不过分。如果你没看懂，说明你的数据结构和算法知识还是比较欠缺，建议补补课。