在Kotlin协程中捕获Exception是否属于反模式？

在协程环境中，堆栈跟踪的实用性不强，这使得异常类型和消息变得极为重要。第三方库抛出的异常可能具有非常通用的类型和消息，导致无法定位引发异常的代码位置——比如使用Kotlin协程gRPC客户端API时出现的io.grpc.StatusException，其堆栈跟踪就非常通用，不包含任何用户创建的函数。

为异常添加更具上下文针对性的消息，常用方法是捕获并重新抛出异常：

try { ... } catch (e: Exception) { throw RuntimeException("unique message", e) }

但这在协程中是众所周知的反模式，因为协程存在特殊的CancellationException，不能意外吞没该异常，否则会破坏协程的取消机制。

那么以下写法是否应被视为反模式，还是完全可行？

try {
   ...
} catch (e: CancellationException) {
   throw e
} catch (e: Exception) {
   throw RuntimeException("unique message", e)
}

结论：这种写法完全可行，不属于反模式 #

理由如下：

• 保留了协程取消信号：明确捕获并重新抛出CancellationException，没有吞没协程取消事件，协程的取消逻辑可以正常执行；
• 增强了异常上下文：对其他异常添加了自定义消息，解决了第三方库异常定位困难的问题，同时通过将原异常作为cause传入，没有丢失原始异常的信息；
• 符合协程异常处理原则：协程异常处理的核心要求就是不能吞没CancellationException，该写法严格遵守了这一规则。

额外注意事项 #

• 尽量避免直接捕获Exception，优先捕获更具体的异常类型，防止意外处理到其他预期外的异常；
• 自定义消息要精准，能清晰标识当前代码的上下文场景，比如“获取用户订单列表时调用gRPC接口失败”，而非模糊的“unique message”；
• 如果项目有自定义异常体系，建议使用自定义异常类代替RuntimeException，让异常结构更清晰，便于后续统一处理。

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