无CoroutineExceptionHandler时，SupervisorJob相对Job的使用价值探讨

一、未设置CoroutineExceptionHandler时，使用SupervisorJob是否有意义？ #

有意义，核心区别在于崩溃发生前的协程行为：

• 当使用Job()时，只要有一个子协程抛出未捕获异常，会立即取消作用域内所有同级子协程，然后异常传播到顶层导致应用崩溃。你的测试里launch1会被中途打断，无法完成。
• 当使用SupervisorJob()时，只有抛出异常的子协程会被取消，其他正常的子协程会继续执行直到完成任务，之后异常才会传播到顶层导致崩溃。这意味着launch1这类正常协程的收尾操作、数据写入等逻辑能完整执行，不会被强制中断。

哪怕最终都会崩溃，SupervisorJob能保证非异常协程的任务完整性，这在很多场景下是有价值的——比如你需要确保用户的本地缓存写入完成，或者日志上报完毕，再接受崩溃。

二、存在子协程未抛出异常却失败的场景吗？ #

当然存在，这类场景的核心是协程被取消或无法正常调度执行，而非主动抛出异常，常见情况包括：

• 父协程/作用域被主动取消：比如调用scope.cancel()，或者绑定的生命周期结束（如Activity销毁时取消对应协程作用域），子协程会被自动取消，此时不会抛出异常，但协程无法完成原定任务；
• 子协程自身Job被取消：调用launch返回的Job对象的cancel()方法，协程会进入取消状态，执行被中断；
• 调度器被关闭：如果协程使用的Dispatcher被手动关闭（比如自定义的线程池Dispatcher调用了shutdown()），协程无法获得执行机会，会以取消状态结束；
• 业务逻辑层面的失败：比如调用suspend风格的网络请求函数，返回Result.failure()或者空值，协程本身没有抛出异常，但从业务角度看任务执行失败。

内容的提问来源于stack exchange，提问作者fraterboots