表示多失败单成功场景的惯用类型是什么？及Maybe a逆场景探讨

嘿，这个问题问到点子上了，我来给你好好梳理下～

针对你说的存在多种失败情况但仅有一种成功情况的场景，在函数式编程圈子里最常用的是类似Result的类型（不同语言命名可能有差异）：

• 比如Haskell里的Either e ()：左边的e用来承载失败的具体原因，右边的()（单元类型）专门表示“没有额外信息的成功”；
• Rust里对应的是Result<(), E>：逻辑完全一致，()代表成功无附加数据，E则存储错误详情；
• 有些语言也会叫ErrorOrVoid这类名字，但核心语义都是“要么失败带原因，要么成功无内容”，这是社区公认的惯用写法。

你提到的Maybe e确实是一种思路，但这里要踩个坑：Maybe的通用约定是Just x代表成功并携带值，Nothing代表失败。如果反过来用Just e表示失败、Nothing表示成功，虽然代码能跑，但完全违背了大家的使用习惯，其他开发者读代码时很容易搞反，所以这种“反常规”的用法非常不推荐。

更合理的有两种方案：

方案1：用标准的Either e ()（或Result<(), E>） #

这是最符合语义直觉的方案：

• Left e（对应Rust的Err(E)）：明确表示失败，e里存具体的失败原因；
• Right ()（对应Rust的Ok(())）：表示成功，单元类型()直接传达“成功没有额外数据”的含义。
  这种方式完全贴合你说的场景，而且是函数式编程里的标准用法，可读性和兼容性都拉满，不用额外造轮子。

方案2：自定义一个表意更直白的专用类型 #

如果觉得Either的单元类型不够直观，也可以自己定义一个更易懂的类型，比如在Haskell里可以这么写：

data OperationResult e = Failure e | Success

或者在Rust里：

enum OperationResult<E> {
    Failure(E),
    Success,
}

这种自定义类型的好处是名字和构造函数都非常直白，Success一眼就懂是成功，Failure(e)明确带错误原因，完全不需要依赖Either的约定，对新手也更友好。

总的来说，优先推荐方案1，毕竟是标准类型，大家都熟；如果团队追求极致的可读性，方案2也是个不错的选择。

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