调度中出现了问题该如何处理-协程异常

前言

java和kotlin原生的异常处理机制都比较简单，用try和catch的组合能够解决很多问题，但是在实际生产环境中，有许多复杂的工作流逻辑，为了保证程序的鲁棒性，必须有更好的异常处理机制。用之前《协程调度》的文章的开头提出的问题。调度者如何更好的接受到每个员工的问题反馈？可以有很多方式，调度者可以放一个反馈问题的信箱，当有问题反馈时，这个信箱可以通知调度者来处理。或者员工遇到问题了直接给调度者打电话处理。又或者员工直接将问题反馈给上一级的领导，直接解决了。上述的这些问题都是在协程中的异常处理框架所要解决的问题，总结如下：

主线程能方便的捕获子线程异常（调度者可以监督每个子流程）
全局异常机制（信箱机制）
异常在协程内应该如何传播（可以决定问题反馈给谁，最终的处理者是谁）

父线程捕获子线程的异常

在一段复杂的工作流的异常处理中，不仅需要简单的全局异常捕获机制，还需要对单个任务进行异常捕获，在java中一般的同步任务我们可以简单的用try,catch关键字进行处理。但在异步任务异常捕获场景中，用原生java的办法就没办法了。在RxJava中，利用回调onError()的方法处理，而对于koltin就很简单了，直接用try，catch就完事，代码例子如下：

suspend fun test1() {
    try {
        coroutineScope {
            launch(newSingleThreadContext("dispather-1")) {
                log(1)
                throw AssertionError()
            }
        }
    } catch (e: AssertionError) {
        log(e)
    }
}
//output
Thread[dispather-1,5,main]1
Thread[main,5,main]java.lang.AssertionError
Thread[main,5,main]end

其实我们可以从output发现，第一行与第二行经历过线程切换，这是kotlin协程框架为我们做的事情。之后我们也会有文章专门分析线程切换相关问题。

全局异常机制

类似java中的线程，kotlin协程也有全局异常处理，比如下面代码：

 private fun scan(offlinePackageSyncScanner: OfflinePackageSyncScanner?) {
        // 这一个信箱
        val handler = CoroutineExceptionHandler { _, exception ->
            log("coroutineStudy Caught $exception")
            offlinePackageSyncScanner?.scannerCallBack?.onExceptionScan(exception as java.lang.Exception)
        }
        // MainScope为Android中的GlobleScope
        MainScope().launch(handler) {
            offlinePackageSyncScanner?.scanAll()
        }
    }

我想对scanAll函数里发生的异常都统一处理，不用再scanAll函数中可能发生异常的地方调用try catch了。这里用CoroutineExceptionHandler()函数构造一个CoroutineExceptionHandler实例handler然后传递给协程构建器launch即可，handler是作为协程构建器中的协程上下文参数的，说明CoroutineExceptionHandler也是CoroutineContext,见如下源码便清晰了

public interface CoroutineExceptionHandler : CoroutineContext.Element{}

public interface Element : CoroutineContext{}

另外有两个点需要说明：

GlobleScope.async()启动的协程，传handler是没有用的。async和launch的源码可以证明这一点：

image.png

即async是没有全局异常处理机制的

lanuch(handler)调用的时机一般都是在没有协程作用域，需要启动协程的时候。

异常传播

还是以前言中所描述的工作流场景，员工遇到问题不总是直接给调度者（领导者）反馈，其可以自己处理掉或者交给他的直接上级处理，该怎么办呢？这就需要用到协程中的异常传播机制。下面是异常传播框架中几个比较重要机制。

coroutineScope：协程默认作用域

指定协程作用域，在该作用域内当自身执行任务失败的时候，会触发双向传播, 看一个例子

suspend fun test12() {
        log(1)
        try {
            coroutineScope {// 1
                log(2)
                launch() {// 2
                    log(3)
                    launch() {// 3
                        log(4)
                        delay(100)
                        throw IOException("Hey!!")
                    }
                    log(5)
                }
                log(6)
                val job = launch {// 4
                    log(7)
                    delay(1000)
                }
                try {
                    log(8)
                    job.join()
                    log("9")
                } catch (e: Throwable) {
                    log("10. $e")
                }
            }
            log(11)
        } catch (e: Throwable) {
            log("12. $e")
        }
        log(13)
    }
// output:
Thread[main,5,main]1
Thread[main,5,main]2
Thread[main,5,main]6
Thread[main,5,main]8
Thread[main,5,main]3
Thread[main,5,main]5
Thread[main,5,main]7
Thread[main,5,main]4
Thread[main,5,main]10. kotlinx.coroutines.JobCancellationException: ScopeCoroutine is cancelling; job=ScopeCoroutine{Cancelling}@35851384
Thread[main,5,main]12. java.io.IOException: Hey!!
Thread[main,5,main]13
Thread[main,5,main]end

在协程3抛出异常后，异常向上传播到父协程域1,1开始通知其余子协程都停止，于是抛出了JobCancellationException异常于是协程4的数字9并没有输出，影响到了协程4的顺利执行，然后协程域1中的异常也会被try{}catch{}捕获到

supervisorScope

指定协程作用域，在该作用域内当自身执行任务失败的时候，只会向下传播去关闭子协程,把上述作用域改成supervisorScope

suspend fun test12() {
        log(1)
        try {
            supervisorScope {// 1
                log(2)
                launch() {// 2
                    log(3)
                    launch() {// 3
                        log(4)
                        delay(100)
                        throw IOException("Hey!!")
                    }
                    log(5)
                }
                log(6)
                val job = launch {// 4
                    log(7)
                    delay(1000)
                }
                try {
                    log(8)
                    job.join()
                    log("9")
                } catch (e: Throwable) {
                    log("10. $e")
                }
            }
            log(11)
        } catch (e: Throwable) {
            log("12. $e")
        }
        log(13)
    }

// output
Thread[main,5,main]1
Thread[main,5,main]2
Thread[main,5,main]6
Thread[main,5,main]8
Thread[main,5,main]3
Thread[main,5,main]5
Thread[main,5,main]7
Thread[main,5,main]4
Exception in thread "main" java.io.IOException: Hey!!
    at coroutine.Exception$test12$2$1$1.invokeSuspend(Exception.kt:271)
    at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
    at kotlinx.coroutines.DispatchedTaskKt.resume(DispatchedTask.kt:175)
    at kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:111)
    at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:307)
    at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl(CancellableContinuationImpl.kt:317)
    at kotlinx.coroutines.CancellableContinuationImpl.resumeUndispatched(CancellableContinuationImpl.kt:399)
    at kotlinx.coroutines.EventLoopImplBase$DelayedResumeTask.run(EventLoop.common.kt:485)
    at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:272)
    at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:79)
    at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:54)
    at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source)
    at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:36)
    at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source)
    at coroutine.ExceptionKt.main(Exception.kt:317)
    at coroutine.ExceptionKt.main(Exception.kt)
Thread[main,5,main]9
Thread[main,5,main]11
Thread[main,5,main]13
Thread[main,5,main]end

观察协程3，再打印数字4字后抛出异常，并没有影响到协程4的执行。总的来说，coroutineScope就是一损俱损的规则，而supervisorScope是自生自灭。

lanuch和async作用域

除了上面两个构建的协程作用域，launch和aysnc也能构建出协程作用域，且构建出的作用域是遵守默认作用域coroutineScope的异常传播机制的。但是他们还是有一定区别，如下

header 1	支持`try{}catch`机制	支持全局异常机制
launch.join()	否	是
async.await()	是	否

造成这种现象的本质原因是launch会调用的join只会关心是否执行完，不关心这段代码执行成功与否，而async调用的await需要关心结果。当然如果你用async.join()是可以的，但是这肯定可以不符合代码设计原则，即async这样调用是没有意义的还不如用launch.join()

总结

kotlin协程的异常捕获机制其实就两点，局部异常捕获和全局异常捕获。总结图如下：
[图片上传失败...(image-6391c7-1588404498453)]