23 | 异常：try-catch居然会不起作用？坑！

（1）Cancel依赖Cancel异常。 （2）SupervisorJob重写了childCancelled=false，导致取消不会向上和兄弟传播。 （3）异常的传播应该是先向上传播，然后都没人处理才会触发协程的CoroutineExceptionHandler，在触发全局默认的CoroutineExceptionHandler。 （4）ExceptionHandler代替try catch不合理，无法清晰的对业务异常有一个认知，不知道是哪里来的，只能通用处理；同时我认为ExceptionHandler或者作为兜底策略也是合理的，子协程对自己的业务进行异常处理，同时顶层协程有一个兜底策略，上报后需要及时让子协程进行处理；这个问题就像Java线程要不要加UnCauthedExceptionHandler【协程也可以加默认的】。

老师，我实验了 CoroutineExceptionHandler ，貌似可以用在局部，还是我哪里搞错了，关键点 + 了一个 Job() 就可以了； 环境：JDK: 11 , Kotlin: 1.6.10, Kotlin coroutine-core: 1.6.0 代码如下： launch { delay(100L) launch(exceptionHandler + Job() ) { // delay(100L) 1 / 0 // Cause Exp } }

由于 Coroutine 是结构化的，当一个子 job 出现异常会导致其他协程都停止运行，在一些场景下并不是我们想要的。我们需要使用 try catch 来将异常捕获在发生异常的地方。 如果使用 supervisorJob 来阻止异常传递的话，CoroutineExceptionHandler 又无法接收到异常，导致我们无法知道哪一个 Job由于什么原因被中止了。这时使用 try catch 可以捕获到对应的异常信息。 言而总之，try catch 在处理协程异常时，还是很有必要的。

思考题： 全部用ExceptionHandler 替代try catch是不合理的，因为在实际编码过程中，我们有时需要在当前上下文合适地处理异常，比如兜底操作，重试等，并不是一味的把异常抛出去，如果都交给顶层就无法很好地处理这些case。类似于Java的UnCauthedExceptionHandler 。

思考题: 个人理解，看场景。有些业务是可以把异常当作分支处理，这种情况，handler就不适合了。

请问，文章中的动画是怎么做的啊？

准则二例子 val job1 = Job() val pJob: Job = launch(myFixedThread) { launch(job1) {//coroutine#3} launch{//CoroutineId(4)} } 照搬的例子，测试时发现job1下的协程也停止了打印 检查发现 "coroutine#3":StandaloneCoroutine{Active}@543fc144, "coroutine#4":StandaloneCoroutine{Cancelling}@32e5773b 问题：打破协程父子结构的子协程coroutine#3（父协程是job1，当前处于Active状态）停止了打印？pJob的cancel没有影响到job1的Active状态，但是coroutine#3不再打印数据

代码段2： launch(Dispatchers.Default) 这里为什么必须使用Default线程池？

关于异常要写对应的异常，不要用父类的Except ion，在使用快捷键给一点代码加上try-catch后，出来的就是父类的题材，那老师我们在编写代码的时候，怎么判断是属于某一个具体的异常？！

以下代码，"End" 都打印了，子 Job 也停止了，为啥程序不能停止？ fun main() = runBlocking { val dispatcher = Executors.newFixedThreadPool(2) { Thread(it, "bqt") }.asCoroutineDispatcher() val pJob = launch(dispatcher) { launch { var i = 0 while (true) { delay(500) i++ println("cJob - $i") } } } delay(2000L) pJob.cancel() pJob.join() println("End") }