Kotlin协程中async和await的常见异常陷阱及正确的异常处理方法

使用Kotlin来做一些异步操作相信大家都非常熟悉了，特别是结合Jetpack的一些组件，使得我们在Android开发中写异步任务非常的方便。

但是，关于在使用协程的时候，个人觉得异常处理这一块是相对来讲是需要花时间去了解的地方，因为在使用过程中还是会遇到一些小坑的，这里记录下之前遇到的坑。

踩一个使用async await时异常处理的坑

kotlin 协程的异常处理官方文档
我们先来看官方的示例：

可以看到，示例代码中在对 async 开启的协程进行异常捕获是在调用 await 时。看打印结果也确实是捕获到了，没什么问题。

按照这个示例代码，我们可能会很自然的就这么用了，比如在ViewModel中写了如下代码：

fun testAsync() {viewModelScope.launch {val deferred = async {LogUtils.e("准备抛出异常")delay(1000)throw Exception("async 抛出了一个异常")}try {deferred.await()} catch (e: Exception) {LogUtils.e("在 await 处捕获到 async的异常了")}LogUtils.e("后续代码继续执行")}}

按照官方给的示例代码来看，async的异常是在调用await的时候才会抛出。那我们在调用await的时候进行try catch,就可以捕获到async抛出的异常，并且程序不会崩溃。
我们来实际运行看一下：

这里我再进入异常处理的时候调用了一下上面的代码，可以发现，app居然崩溃了。下面我们来看看打印的日志

可以看到，我们明明在await的时候已经捕获到异常了，为什么App还会崩溃呢？

如果你仔细看官方示例中的注释，会发现这么两个单词 root coroutine

直接说结果：

当async作为根协程时，被封装到deferred对象中的异常才会在调用await时抛出。
如果async作为一个子协程时，那么异常并不会等到调用await时抛出，而是立刻抛出异常。

这也就是为什么我们明明在await的地方进行try catch，但是程序仍然会崩溃的原因。
因为被立刻抛出的异常没有被得到处理，所以只能崩溃了。

只不过官方文档并没有明确的说明作为子协程的情况异常是怎样的，所以，我之前在这里是踩过坑的。

这里你可能就有疑问了，不对啊，看日志明明就是await的时候才抛出的异常，你怎么能说是立刻抛出的呢，怎么证明呢。
我只能说：

很简单，我们在await之前加个延时，看看日志打印就知道了。
代码如下，跟上面一样，直接加了个延时。

fun testAsync() {viewModelScope.launch {val deferred = async {LogUtils.e("准备抛出异常")delay(1000)throw Exception("async 抛出了一个异常")}/*加个延时 主要是验证异常是不是在await的时候抛出*/delay(2000)try {deferred.await()} catch (e: Exception) {LogUtils.e("在 await 处捕获到 async的异常了")}LogUtils.e("后续代码继续执行")}}

再来看看运行情况，可以看到，await的try catch的日志就没有机会打印了。为啥呢，因为上面的代码已经出异常了，程序都崩了，就没有等2秒继续执行的机会了。上面的代码会打印是因为执行的很快，所以才会给你一种错觉是以为还是在await的时候抛出的异常。

下面我们再来验证下作为顶级作用域时是不是真的是在调用await的时候抛出的异常：
同样的处理方式，只不过此时async变成了顶级作用域

fun testTopAsync() {/*顶级作用域的async*/val deferred = viewModelScope.async {LogUtils.e("准备抛出异常")delay(1000)throw Exception("async 抛出了一个异常")}viewModelScope.launch {/*加个延时 主要是验证异常是不是在await的时候抛出*/delay(2000) try {deferred.await()} catch (e: Exception) {LogUtils.e("在 await 处捕获到 async的异常了")}LogUtils.e("后续代码继续执行")}}

可以看到，确实是在2秒后的await时才捕获到异常，app也没有崩溃。

kotlin协程异常处理的正确姿势

这里只是我自己觉得正确的处理方式

首先，在使用协程时，一定要加 coroutineexceptionhandler

这个是对当前协程作用域内的异常做一个兜底，也就是作用域中未被捕获到的异常会最终交给coroutineexceptionhandler处理，这样，至少能保证你的App不会崩溃

我们来看下面的代码：

/*异常处理*/private val exceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->LogUtils.e("exceptionHandler:${throwable}")}fun testAsync() {viewModelScope.launch(exceptionHandler) {val deferred = async {LogUtils.e("准备抛出异常")delay(1000)throw Exception("async 抛出了一个异常")}/*加个延时 主要是验证异常是不是在await的时候抛出*/delay(2000)try {deferred.await()} catch (e: Exception) {LogUtils.e("在 await 处捕获到 async的异常了")}LogUtils.e("后续代码继续执行")}}

还是之前的代码，只不过加了个 CoroutineExceptionHandler ，这个CoroutineExceptionHandler 就不多啰嗦了，官网文档介绍的也比较详细了。

然后看一下运行效果：

可以看到
async抛出的未被捕获到的异常就被
CoroutineExceptionHandler 给处理掉了，这样即使你的协程块内有一些忘处理的异常抛出，也不会导致App崩溃

至于加了CoroutineExceptionHandler 后 CoroutineScope和 supervisorScope的区别这里就不多介绍了，官网介绍的都比较清楚。

来简单总结下：

• 对每个协程内部进行try cath 是最保险的做法，简单粗暴，虽然麻烦，但是不会出错，稳得一批
• 不管有没有做try catch处理，都一定要在根作用域加上CoroutineExceptionHandler ，以防万一
• 使用async await时要注意下作用域的问题，以免出现跟预期不一样的结果

好了，本文就是这样，希望能帮到你

如果你觉得本文对你有帮助，麻烦动动手指顶一下，可以帮助到更多的开发者，如果文中有什么错误的地方，还望指正，转载请注明转自喻志强的博客 ，谢谢！