前言
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)]
网友评论