使用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时要注意下作用域的问题，以免出现跟预期不一样的结果
好了，本文就是这样，希望能帮到你
如果你觉得本文对你有帮助，麻烦动动手指顶一下，可以帮助到更多的开发者，如果文中有什么错误的地方，还望指正，转载请注明转自喻志强的博客 ，谢谢！