kotlin协程的异常处理：

我们看到 handleFatalException实际是调用了 handleCoroutineException方法。 handleCoroutineException是 kotlinx.coroutines库中的顶级函数

public fun handleFatalException(exception: Throwable?, finallyException: Throwable?) {    //省略....
    handleCoroutineException(this.delegate.context, reason)
}
复制代码

public fun handleCoroutineException(context: CoroutineContext, exception: Throwable) {    try {
        context[CoroutineExceptionHandler]?.let {
            it.handleException(context, exception)            return
        }
    } catch (t: Throwable) {
        handleCoroutineExceptionImpl(context, handlerException(exception, t))        return
    }
    handleCoroutineExceptionImpl(context, exception)
}
复制代码

我们看到 handleCoroutineException会先从协程上下文拿 CoroutineExceptionHandler，如果我们没有定义的 CoroutineExceptionHandler话，它将会调用 handleCoroutineExceptionImpl抛出一个 uncaughtExceptionHandler导致我们程序崩溃退出。

internal actual fun handleCoroutineExceptionImpl(context: CoroutineContext, exception: Throwable) {    for (handler in handlers) {        try {
            handler.handleException(context, exception)
        } catch (t: Throwable) {
            val currentThread = Thread.currentThread()
            currentThread.uncaughtExceptionHandler.uncaughtException(currentThread, handlerException(exception, t))
        }
    }
    val currentThread = Thread.currentThread()
    currentThread.uncaughtExceptionHandler.uncaughtException(currentThread, exception)
}
复制代码

不知道各位是否理解了上面的流程，笔者最开始的时候也是被这里来来回回的。绕着晕乎乎的。如果没看懂的话，可以休息一下，揉揉眼睛，倒杯热水，再回过头捋一捋。

好滴，到此处为止。我们已经大概的了解kotlin协程中异常是如何抛出的,下面我们就不再不过多延伸。下面我们来说说异常的处理。

协程的异常处理

kotlin协程异常处理我们要分成两部分来看，通过上面的分解我们知道一种异常是通过 resumeWithException抛出的，还有一种异常是直接通过 CoroutineExceptionHandler抛出，那么我们现在就开始讲讲如何处理异常。

第一种：当然就是我们最常用的 try..catch啦，只要有异常崩溃我就先 try..catch下，先不管流程对不对，我先保住我的程序不能崩溃。

private fun testException(){
    GlobalScope.launch{
        launch(start = CoroutineStart.UNDISPATCHED) {
            Log.d("${Thread.currentThread().name}", " 我要开始抛异常了")            try {                throw NullPointerException("异常测试")
            } catch (e: Exception) {
                e.printStackTrace()
            }
        }
        Log.d("${Thread.currentThread().name}", "end")
    }
}
复制代码

D/DefaultDispatcher-worker-1:  我要开始抛异常了
W/System.err: java.lang.NullPointerException: 异常测试
W/System.err:     at com.carman.kotlin.coroutine.MainActivity$testException$1$1.invokeSuspend(MainActivity.kt:252)
W/System.err:     at com.carman.kotlin.coroutine.MainActivity$testException$1$1.invoke(Unknown 
//省略...
D/DefaultDispatcher-worker-1: end
复制代码

诶嘿，这个时候我们程序没有崩溃，只是输出了警告日志而已。那如果遇到 try..catch搞不定的怎么办，或者遗漏了需要 try..catch的位置怎么办。比如：

private fun testException(){    var a:MutableList = mutableListOf(1,2,3)
    GlobalScope.launch{
       launch {
            Log.d("${Thread.currentThread().name}","我要开始抛异常了" )            try {
                launch{
                    Log.d("${Thread.currentThread().name}", "${a[1]}")
                }
                a.clear()
            } catch (e: Exception) {
                e.printStackTrace()
            }
        }
        Log.d("${Thread.currentThread().name}", "end")
    }
}
复制代码

D/DefaultDispatcher-worker-1: endD/DefaultDispatcher-worker-2: 我要开始抛异常了
E/AndroidRuntime: FATAL EXCEPTION: DefaultDispatcher-worker-2
    Process: com.carman.kotlin.coroutine, PID: 5394
    java.lang.IndexOutOfBoundsException: Index: 1, Size: 0
        at java.util.ArrayList.get(ArrayList.java:437)
        at com.carman.kotlin.coroutine.MainActivity$testException$1$1$1.invokeSuspend(MainActivity.kt:252)
        at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
        at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
        at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
        at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)
复制代码

当你以为使用 try..catch就能捕获的时候，然而实际并没有。这是因为我们的 try..catch使用方式不对，我们必须在使用 a[1]时候再用 try..catch捕获才行。那就有人会想那我每次都记得使用 try..catch就好了。

是，当然没问题。但是你能保证你每次都能记住吗，你的同一战壕里的战友会记住吗。而且当你的逻辑比较复杂的时候，你使用那么多 try..catch你代码阅读性是不是降低了很多后，你还能记住哪里有可能会出现异常吗。

这个时候就需要使用协程上下文中的 CoroutineExceptionHandler。我们在上一篇文章讲解协程上下文的时候提到过，它是协程上下文中的一个 Element，是用来捕获协程中未处理的异常。

public interface CoroutineExceptionHandler : CoroutineContext.Element {
    public companion object Key : CoroutineContext.Key
    public fun handleException(context: CoroutineContext, exception: Throwable)
}
复制代码

我们稍作修改：

private fun testException(){
    val exceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->
        Log.d("exceptionHandler", "${coroutineContext[CoroutineName]} ：$throwable")
    }
     GlobalScope.launch(CoroutineName("异常处理") + exceptionHandler){
         val job = launch{
             Log.d("${Thread.currentThread().name}","我要开始抛异常了" )
             throw NullPointerException("异常测试")
         }
         Log.d("${Thread.currentThread().name}", "end")
     }
}
复制代码

D/DefaultDispatcher-worker-1: 我要开始抛异常了
D/exceptionHandler: CoroutineName(异常处理) ：java.lang.NullPointerException: 异常测试
D/DefaultDispatcher-worker-2: end复制代码

这个时候即使我们没有使用 try..catch去捕获异常，但是异常还是被我们捕获处理了。是不是感觉异常处理也没有那么难。那如果按照上面的写，我们是不是得在每次启动协程的时候，也需要跟 try..catch一样都需要加上一个 CoroutineExceptionHandler呢？ 这个时候我们就看出来，各位是否真的有吸收前面讲解的知识：

• 第一种：我们上面讲解的 协程作用域部分你已经消化吸收，那么恭喜你接下来的你可以大概的过一遍或者选择跳过了。因为接下来的部分和 协程作用域中说到的内容大体一致。

• 第二种：除第一种的，都是第二种。那你接下来你就得认证仔细的看了。

我们之前在讲到 协同作用域和 主从(监督)作用域的时候提到过，异常传递的问题。我们先来看看 协同作用域:

• 协同作用域如果子协程抛出未捕获的异常时，会将异常传递给父协程处理，如果父协程被取消，则所有子协程同时也会被取消。

容我盗个官方图

默认情况下，当协程因出现异常失败时，它会将异常传播到它的父级，父级会取消其余的子协程，同时取消自身的执行。最后将异常在传播给它的父级。当异常到达当前层次结构的根，在当前协程作用域启动的所有协程都将被取消。

我们在前一个案例的基础上稍作做一下修改，只在父协程上添加 CoroutineExceptionHandler，照例上代码：

private fun testException(){
    val exceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->
        Log.d("exceptionHandler", "${coroutineContext[CoroutineName]} 处理异常 ：$throwable")
    }
    GlobalScope.launch(CoroutineName("父协程") + exceptionHandler){
        val job = launch(CoroutineName("子协程")) {
            Log.d("${Thread.currentThread().name}","我要开始抛异常了" )            for (index in 0..10){
            launch(CoroutineName("孙子协程$index")) {
                Log.d("${Thread.currentThread().name}","${coroutineContext[CoroutineName]}" )
            }
        }
            throw NullPointerException("空指针异常")
        }        for (index in 0..10){
            launch(CoroutineName("子协程$index")) {
                Log.d("${Thread.currentThread().name}","${coroutineContext[CoroutineName]}" )
            }
        }
        try {
            job.join()
        } catch (e: Exception) {
            e.printStackTrace()
        }
        Log.d("${Thread.currentThread().name}", "end")
    }
}
复制代码

D/DefaultDispatcher-worker-3: 我要开始抛异常了
W/System.err: kotlinx.coroutines.JobCancellationException: StandaloneCoroutine is cancelling; job=StandaloneCoroutine{Cancelling}@f6b7807
W/System.err: Caused by: java.lang.NullPointerException: 空指针异常
W/System.err:     at com.carman.kotlin.coroutine.MainActivity$testException$1$job$1.invokeSuspend(MainActivity.kt:26//省略...
D/DefaultDispatcher-worker-6: end
D/exceptionHandler: CoroutineName(父协程) 处理异常 ：java.lang.NullPointerException: 空指针异常
复制代码

我们看到子协程 job的异常被父协程处理了，无论我下面开启多少个子协程产生异常，最终都是被父协程处理。但是有个问题是： 因为异常会导致父协程被取消执行，同时导致后续的所有子协程都没有执行完成(可能偶尔有个别会执行完)。那可能就会是有人问了，这种做法的意义和应用场景是什么呢？

如果有一个页面，它最终展示的数据，是通过请求多个服务器接口的数据拼接而成的，而其中某一个接口出问题都将不进行数据展示，而是提示加载失败。那么你就可以使用上面的方案去做，都不用管它们是谁报的错，反正都是统一处理，一劳永逸。类似这样的例子我们在开发中应该经常遇到。

但是另外一个问题就来了。例如我们APP的首页，首页上展示的数据五花八门。如：广告，弹窗，未读状态，列表数据等等都在首页存在，但是他们相互之间互不干扰又不关联，即使其中某一个失败了也不影响其他数据展示。那通过上面的方案，我们就没办法处理。

这个时候我们就可以通过 主从(监督)作用域的方式去实现，与 协同作用域一致，区别在于该作用域下的协程取消操作的单向传播性，子协程的异常不会导致其它子协程取消。我再盗个官方图：

我们在讲解 主从(监督)作用域的时候提到过，要实现 主从(监督)作用域需要使用 supervisorScope或者 SupervisorJob。这里我们需要补充一下，我们在使用 supervisorScope其实用的就是 SupervisorJob。 这也是为什么使用 supervisorScope与使用 SupervisorJob协程处理是一样的效果。

/**
 *  省略...
 * but overrides context's [Job] with [SupervisorJob].
 * 省略...
 */public suspend fun  supervisorScope(block: suspend CoroutineScope.() -> R): R {   //省略...}
复制代码

这段是摘自官方文档的，其他的我把它们省略了，只留了一句：" SupervisorJob会覆盖上下文中的 Job"。这也就说明我们在使用 supervisorScope的就是使用的 SupervisorJob。我们先用 supervisorScope实现以下我们上面提到的案例：

private fun testException(){
    val exceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->
        Log.d("exceptionHandler", "${coroutineContext[CoroutineName].toString()} 处理异常 ：$throwable")
    }
    GlobalScope.launch(exceptionHandler) {
        supervisorScope {
            launch(CoroutineName("异常子协程")) {
                Log.d("${Thread.currentThread().name}", "我要开始抛异常了")
                throw NullPointerException("空指针异常")
            }            for (index in 0..10) {
                launch(CoroutineName("子协程$index")) {
                    Log.d("${Thread.currentThread().name}正常执行", "$index")                    if (index %3 == 0){
                        throw NullPointerException("子协程${index}空指针异常")
                    }
                }
            }
        }
    }
}
复制代码

D/DefaultDispatcher-worker-1: 我要开始抛异常了
D/exceptionHandler: CoroutineName(异常子协程) 处理异常 ：java.lang.NullPointerException: 空指针异常
D/DefaultDispatcher-worker-1正常执行: 1
D/DefaultDispatcher-worker-1正常执行: 2
D/DefaultDispatcher-worker-3正常执行: 0
D/DefaultDispatcher-worker-1正常执行: 3
D/exceptionHandler: CoroutineName(子协程0) 处理异常 ：java.lang.NullPointerException: 子协程0空指针异常
D/exceptionHandler: CoroutineName(子协程3) 处理异常 ：java.lang.NullPointerException: 子协程3空指针异常
D/DefaultDispatcher-worker-4正常执行: 4
D/DefaultDispatcher-worker-4正常执行: 5
D/DefaultDispatcher-worker-5正常执行: 7
D/DefaultDispatcher-worker-3正常执行: 6
D/DefaultDispatcher-worker-5正常执行: 8
D/DefaultDispatcher-worker-5正常执行: 9
D/exceptionHandler: CoroutineName(子协程9) 处理异常 ：java.lang.NullPointerException: 子协程9空指针异常
D/exceptionHandler: CoroutineName(子协程6) 处理异常 ：java.lang.NullPointerException: 子协程6空指针异常
D/DefaultDispatcher-worker-2正常执行: 10
复制代码

可以看到即使当中有多个协程都出现问题，我们还是能够让所有的子协程执行完成。这个时候我们用这样方案是不是就可以解决，我们首页多种数据互不干扰的刷新问题了，同也能够在出现异常的时候统一处理。

那我们在用 SupervisorJob实现一遍，看看是不是和 supervisorScope一样的，代码奉上：

private fun testException(){
    val exceptionHandler = CoroutineExceptionHandler { coroutineContext, throwable ->
        Log.d("exceptionHandler", "${coroutineContext[CoroutineName].toString()} 处理异常 ：$throwable")
    }
    val supervisorScope = CoroutineScope(SupervisorJob() + exceptionHandler)
    with(supervisorScope) {
        launch(CoroutineName("异常子协程")) {
            Log.d("${Thread.currentThread().name}", "我要开始抛异常了")
            throw NullPointerException("空指针异常")
        }        for (index in 0..10) {
            launch(CoroutineName("子协程$index")) {
                Log.d("${Thread.currentThread().name}正常执行", "$index")                if (index % 3 == 0) {
                    throw NullPointerException("子协程${index}空指针异常")
                }
            }
        }
    }
}
复制代码

可以看到我们通过 CoroutineScope创建一个 SupervisorJob的 supervisorScope，然后再通过 with(supervisorScope)是不是就变得跟直接使用 supervisorScope一样了。

D/DefaultDispatcher-worker-1: 我要开始抛异常了
D/DefaultDispatcher-worker-2正常执行: 0
D/exceptionHandler: CoroutineName(子协程0) 处理异常 ：java.lang.NullPointerException: 子协程0空指针异常
D/exceptionHandler: CoroutineName(异常子协程) 处理异常 ：java.lang.NullPointerException: 空指针异常
D/DefaultDispatcher-worker-2正常执行: 1
D/DefaultDispatcher-worker-2正常执行: 2
D/DefaultDispatcher-worker-4正常执行: 3
D/exceptionHandler: CoroutineName(子协程3) 处理异常 ：java.lang.NullPointerException: 子协程3空指针异常
D/DefaultDispatcher-worker-1正常执行: 4
D/DefaultDispatcher-worker-4正常执行: 5
D/DefaultDispatcher-worker-4正常执行: 6
D/exceptionHandler: CoroutineName(子协程6) 处理异常 ：java.lang.NullPointerException: 子协程6空指针异常
D/DefaultDispatcher-worker-4正常执行: 8
D/DefaultDispatcher-worker-3正常执行: 7
D/DefaultDispatcher-worker-2正常执行: 9
D/exceptionHandler: CoroutineName(子协程9) 处理异常 ：java.lang.NullPointerException: 子协程9空指针异常
D/DefaultDispatcher-worker-3正常执行: 10
复制代码

当然，我们在使用协程的时候，可能某个协程需要自己处理自己的异常，这个时候只需要在这个协程的上下文中添加 CoroutineExceptionHandler即可。毕竟按需使用，谁也不知道产品又会有什么奇怪的想法。

好了，到现在我们也基本的知道协程中的异常产生流程，和按需处理协程中的异常问题。如果您还有什么不清楚的地方，可以自己动手实验一下或者在下方留言、私信笔者等方式，我会在看到消息的第一时间处理。

预告以及意见收集

在下一章节中，我们将会进入到实际的Android开发中，我们会先构建一个基础APP的框架，封装一些常用的协程方法和请求方式，至于具体的实战项目类型，我想征求一下大家的意见，然后根据反馈的实际情况再来决定，欢迎大家踊跃的提出意见。

最后：祝愿大家都能写出完美的BUG，让测试都无法找到BUG所在。

作者：一个被摄影耽误的程序猿
链接： https://juejin.cn/post/6954250061207306253
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。