基于ArrowKt与Repository的单条数据查询返回方案最优实践探讨

这个问题没有绝对统一的标准答案，核心要结合业务场景中"未找到实体"是否属于异常情况来判断：

当"未找到"属于业务异常时，返回Left更优 #

多数场景下，查询单条数据的逻辑是基于「该实体理应存在」的前提：比如根据已登录用户的ID查用户信息、根据已生成的订单ID查订单详情。这种情况下，"未找到"属于异常（比如数据被误删、缓存与DB不一致），返回Left（携带NotFound类型的错误）是更合理的选择：

• 符合「失败早暴露」原则，能快速定位数据异常问题，避免Null在调用链中传播引发NPE；
• 上层调用方无需在每一处都做空检查，可通过统一的异常拦截逻辑处理这类场景，减少冗余代码。

举个伪代码示例：

// Repository层方法
fun getUserById(userId: String): Either<AppError, User> {
    val user = db.query("SELECT * FROM users WHERE id = ?", userId)
    return if (user != null) {
        Right(user)
    } else {
        Left(AppError.NotFound("User $userId not found"))
    }
}

// 上层调用
val result = userRepository.getUserById(currentUserId)
result.fold(
    onLeft = { error -> handleError(error) }, // 统一处理异常
    onRight = { user -> proceedWithUser(user) } // 无需空检查，直接使用
)

当"未找到"属于正常业务逻辑时，返回带Null的Right/Optional更合适 #

如果查询的目的本身就是判断实体是否存在（比如注册时根据邮箱查是否已有用户、搜索冷门关键词找商品），"未找到"是预期内的正常流程分支，这时候返回携带Null的Right（或者用Optional类型）更合适：

• 避免将正常业务逻辑错误地归类为"异常"，减少不必要的异常处理分支；
• 调用方可以清晰识别这是一个合法的流程分支，针对性处理（比如注册场景下直接进入下一步）。

总结 #

回到你的观点：多数业务场景中，查询单条数据是基于「实体应该存在」的预期，这时候返回Left确实更优——既减少了重复的空检查代码，也能更早发现数据层面的异常问题。最终选择还是要锚定具体业务场景，明确"未找到"到底是异常还是正常流程。

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