函数式编程中抛出异常的时机选择及与Maybe/Either的对比

一、两个业务场景的处理选择 #

1. JSON解析失败场景 #

优先选择返回Either<ParseError, UserDTO>（或类似带错误信息的容器类型），而非抛出异常或返回Maybe<User>。

• 原因：JSON解析失败是可预见的业务错误，并非程序运行时的意外故障。Maybe仅能表示“值存在/不存在”，但解析失败有具体原因（如格式错误、字段缺失、类型不匹配），Either可以携带这些错误详情，让调用方明确知道失败根源。
• 若依赖全局异常处理器，会混淆业务错误与系统异常，调用方无法通过返回值直观判断失败类型，直接破坏函数的引用透明性——纯函数要求相同输入必返回相同输出，异常会让函数在相同输入下可能抛出不同异常，违背纯函数特性。

2. 用户不存在场景 #

返回Maybe<User>更贴合函数式编程风格。

• 原因：“根据ID找不到用户”是业务逻辑中完全可预见的情况，属于“值缺失”的范畴，Maybe正是用来建模这种“存在或缺失”的场景。
• 若抛出异常，会把正常的业务逻辑分支转为异常流，调用方必须通过try-catch处理，而非通过返回值的模式匹配覆盖所有分支，违背FP中“用值表示所有状态”的核心原则。

二、函数式编程中是否应使用异常？ #

需严格限制异常的使用范围：仅用异常处理不可预见的系统级故障，例如数据库连接突然中断、内存耗尽、硬件故障等。这些属于程序无法提前预见和通过业务逻辑修复的意外情况，不属于业务逻辑范畴。

所有可预见的业务错误或状态缺失，都应该用Maybe、Either这类函子建模，将错误/缺失作为函数返回值的一部分，而非通过异常抛出。

三、用异常替代Maybe/Either的最大隐患 #

1. 破坏引用透明性：纯函数要求相同输入必须返回相同输出，异常会让函数在相同输入下可能抛出不同异常（例如依赖外部状态时），导致函数不再纯，无法进行缓存、测试、逻辑推理等FP中的常规操作。
2. 隐藏错误路径：异常流是“隐性”的，调用方若不查看函数文档或源码，根本无法知晓函数会抛出哪些异常，极易遗漏错误处理，引发运行时崩溃。而Maybe/Either是“显性”的，返回值明确告知调用方存在多种可能结果，必须处理所有分支。
3. 难以组合与链式调用：FP的核心是函数组合，Maybe/Either支持map、flatMap等高阶函数，可轻松链式处理业务逻辑。而异常需要嵌套try-catch，代码会变得臃肿且难以维护，违反“关注点分离”原则。

四、FP应用中抛异常的经验法则 #

• 仅对“真正的意外”抛异常：比如系统级故障、不可恢复的错误，这类错误不属于业务逻辑，也无法通过业务代码修复。
• 业务逻辑分支全部用值表示：无论成功、值缺失还是业务错误，都封装在Maybe、Either或自定义代数数据类型（ADT）中，让调用方通过模式匹配或高阶函数处理所有可能情况。
• 杜绝“控制流异常”：不要用异常替代正常的条件分支（比如用异常处理“用户不存在”这种可预见情况），这会让代码逻辑混乱，难以理解和调试。

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