如何在Kotlin Arrow中处理逻辑错误并区分多失败路径

我完全懂你现在的感受——Arrow的类型化错误处理文档看的时候好像懂了，但真要写代码落地就卡壳了，尤其是要区分「可恢复逻辑错误」和「需冒泡的意外异常」这两种不同的失败路径。咱们结合你给出的代码示例，一步步把这个问题拆解清楚。

首先，核心思路是用密封类定义不同层级的错误类型，这样就能在编译阶段就把所有可能的失败路径都明确下来，避免后续处理时遗漏。

第一步：定义区分错误类型的密封类 #

咱们先创建一个密封类，把「可恢复的逻辑错误」和「意外异常」分开：

sealed class AppError {
    // 可恢复的逻辑错误：比如验证不通过，用户可以修正的问题
    data class ValidationError(val message: String) : AppError()
    // 意外异常：比如空指针、IO错误这类不可预见的问题，需要向上冒泡
    data class UnexpectedError(val cause: Throwable) : AppError()
}

第二步：改造验证函数，返回带类型的错误 #

接下来修改你的validateName函数，让它返回Either<AppError, String>——Either的Left分支放错误，Right分支放成功结果。这样每一次验证的结果都能明确区分是哪种错误：

import arrow.core.Either
import arrow.core.Left
import arrow.core.Right

fun validateName(value: String): Either<AppError, String> {
    return try {
        if (value.length < 4) {
            // 名称长度不够属于可恢复的逻辑错误，包装成ValidationError
            Left(AppError.ValidationError("名称长度不能少于4个字符：$value"))
        } else {
            // 验证通过，返回成功值
            Right(value)
        }
    } catch (e: Exception) {
        // 捕获运行时的意外异常，包装成UnexpectedError
        Left(AppError.UnexpectedError(e))
    }
}

第三步：处理多验证场景的两种方式 #

现在看你的doValidation函数，要调用三次验证，这里分两种常见场景处理：

场景1：快速失败（只要一个验证不通过就立即返回）

如果你的需求是只要有一个验证失败就停止后续检查，用Either的flatMap链式调用就行：

fun doValidation(): Either<AppError, List<String>> {
    val v1 = "123abc"
    val v2 = "abc"
    val v3 = "1234"

    return validateName(v1)
        .flatMap { validV1 ->
            validateName(v2)
                .flatMap { validV2 ->
                    validateName(v3)
                        .map { validV3 ->
                            listOf(validV1, validV2, validV3)
                        }
                }
        }
}

场景2：收集所有验证错误（适合表单类场景）

如果需要把所有验证错误都收集起来一起返回（比如用户填了多个错误项，一次性提示），那Arrow的Validated会更合适。先把验证函数改成返回ValidatedNel<AppError, String>（Nel是Non-Empty List，用来保证至少有一个错误）：

import arrow.core.Validated
import arrow.core.ValidatedNel
import arrow.core.invalidNel
import arrow.core.valid
import arrow.core.zip

fun validateName(value: String): ValidatedNel<AppError, String> {
    return try {
        if (value.length < 4) {
            AppError.ValidationError("名称长度不能少于4个字符：$value").invalidNel()
        } else {
            value.valid()
        }
    } catch (e: Exception) {
        AppError.UnexpectedError(e).invalidNel()
    }
}

fun doValidation(): ValidatedNel<AppError, List<String>> {
    val v1 = "123abc"
    val v2 = "abc"
    val v3 = "1234"

    // 用zip把多个验证结果合并，收集所有错误
    return validateName(v1)
        .zip(validateName(v2), validateName(v3)) { validV1, validV2, validV3 ->
            listOf(validV1, validV2, validV3)
        }
}

第四步：处理最终结果，区分三种路径 #

最后调用doValidation后，用fold方法来处理三种情况：成功、可恢复错误、意外异常：

fun main() {
    val result = doValidation()
    
    // 用fold分别处理错误和成功分支
    result.fold(
        { errors ->
            errors.forEach { error ->
                when (error) {
                    is AppError.ValidationError -> {
                        // 处理可恢复逻辑错误：比如提示用户修正输入
                        println("验证失败：${error.message}")
                    }
                    is AppError.UnexpectedError -> {
                        // 处理意外异常：比如上报监控、重新抛出
                        println("发生意外错误：${error.cause?.message ?: "未知错误"}")
                        throw error.cause ?: RuntimeException("未知意外错误")
                    }
                }
            }
        },
        { validValues ->
            // 处理成功场景：返回结果或者继续后续业务逻辑
            println("所有验证通过，结果：$validValues")
        }
    )
}

这样下来，你就清晰区分了三种路径：

• 成功：进入Right/Valid分支，拿到正常返回值
• 逻辑错误：进入Left/Invalid分支的ValidationError，做可恢复处理
• 意外异常：进入Left/Invalid分支的UnexpectedError，做冒泡或上报处理

备注：内容来源于stack exchange，提问作者pbuchheit