f# - 模式匹配，F# 与 Erlang

Question

在 Erlang 中，我们鼓励您不要匹配您实际上并未处理的模式。例如:

case (anint rem 10) of
    1 -> {ok, 10}
    9 -> {ok, 25}
end;

是一种被鼓励的风格，其他可能的结果会导致 badmatch结果。这与 Erlang 中的“让它崩溃”的理念一致。

另一方面，F# 会在等效的 F# 代码中发出“不完整的模式匹配”，例如 here .

问题:为什么 F# 不删除警告，有效地通过增加每个模式匹配与等效于的语句

|_ -> failwith "badmatch"

并使用“让它崩溃”的哲学？

编辑 :到目前为止有两个有趣的答案:要么避免在不处理代数数据类型的所有情况时可能出现的错误；或者因为.Net平台。找出哪个的一种方法是检查 OCaml。那么，OCaml 中的默认行为是什么？

编辑 : 消除没有Erlang背景的.Net人的误解。 Erlang 哲学的重点不是产生总是崩溃的坏代码。让它崩溃意味着 let some other process fix the error .与其编写函数使其可以处理所有可能的情况，不如让调用者(例如)处理自动抛出的坏情况。对于那些有 Java 背景的人来说，这就像具有检查异常的语言之间的区别，该语言必须声明它可能随每个可能的异常返回的所有内容，以及拥有一种语言，其中函数可能会引发未明确声明的异常。

Answer 1

F#(以及其他具有模式匹配的语言，如 Haskell 和 O'Caml)确实隐式添加了一个引发异常的案例。

在我看来，拥有完整模式匹配并注意警告的最有值(value)的原因是，通过扩展数据类型可以轻松重构，因为编译器会警告您尚未使用新的代码进行更新案件。

另一方面，有时确实有一些案例应该被排除在外，然后不得不放入一个包含通常是糟糕错误消息的包罗万象的案例是很烦人的。所以这是一个权衡。

为了回答您的编辑，这也是 O'Caml(以及带有 -Wall 的 Haskell)中的默认警告。