Kotlin结合Spring的异常处理：查询无结果时返回可空值还是抛出异常？

首先要明确Roman的观点并没有被曲解的空间：他说的捕获异常用作业务流程控制属于代码坏味道，和你能不能抛异常、在哪里抛异常完全是两个问题。至于你提到的场景，两个方案没有绝对的对错，只看是否匹配你的业务逻辑和架构设计：

优先选择返回可空类型的情况 #

• 「目标条目不存在」属于业务流程内的预期分支，比如用户输入了任意ID查询资源，查询不到是完全正常的用户行为
• 该Service函数有可能被非Controller的上下文调用（比如内部RPC、定时任务、单元测试），返回可空类型可以避免把HTTP相关的错误逻辑耦合进业务层，函数签名fun queryEntry(id: Long): Entry?本身就能清晰传递“可能无返回值”的语义，完全符合Kotlin空安全的设计理念
• 就算你现在需要统一返回404状态，也可以在Controller层做极简的判空抛出：

  @GetMapping("/entry/{id}")
  fun getEntry(@PathVariable id: Long): Entry {
      return entryService.queryEntry(id) ?: throw ResourceNotFoundException("条目$id不存在")
  }
  

  异常只在传输层抛出，业务层完全不需要感知上层的错误处理逻辑，可复用性和可测试性都更强。

适合直接抛出异常的情况 #

• 「目标条目不存在」属于真正的非预期错误，比如前面的业务逻辑已经校验过该ID对应条目存在，后续的内部关联查询却查不到，这种情况本身就属于代码逻辑异常，抛异常打断流程、留下栈信息方便排查是合理的
• 你确定该Service函数永远只会被Controller调用，且所有“查询不到”的场景都对应固定的错误码，不需要任何额外的分支处理

另外必须纠正一个误区：哪怕配置了全局异常处理器，也绝对不能随意抛异常。异常本身有生成栈快照的性能开销，更重要的是用异常代替正常分支控制会大幅降低代码可读性——后续维护的开发者不可能读遍每个函数的内部实现去猜它会抛什么异常，函数签名本身的语义才是最可靠的契约。

如果想要兼顾两者的优势，也可以用密封类封装返回结果，把所有可能的业务结果都显式定义出来，比单纯的可空类型表意更丰富：

sealed interface QueryResult<out T> {
    data class Success<T>(val data: T) : QueryResult<T>
    data object NotFound : QueryResult<Nothing>
    data class PermissionDenied(val reason: String) : QueryResult<Nothing>
}

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