异常处理中的选项与异常

Question

使用F＃option类型一段时间之后，我意识到它可以用于处理异常情况。我可以在以下示例中使用option或Exception：

1. 在不常见的情况下，List / Array / Seq模块中的find函数会引发KeyNotFoundException，而在这些情况下，相应的tryFind对应函数会返回None。
2. 当我进行回溯（解决N-queens，Sudoku等）时，每当分支没有解决方案时，我可以引发异常并稍后捕获它或返回None以匹配该值以回溯。在我们找到解决方案之前，这些情况经常发生。

我的印象是option是一种功能更强大的方法，而Exception在.NET平台中更常用。

在可用性，性能等方面，option和Exception在异常处理方面有何区别？在哪种情况下使用技术比使用其他技术更好？

Answer 1

CLR使抛出和捕获异常的操作非常昂贵。仅仅因为这个原因，你应该更喜欢像Option这样的结构来报告预期的失败。如果失败确实异常且几乎无法恢复，请继续并抛出异常。但是正如你所注意到的那样，在搜索过程中回溯等事情并不常见，如果你用异常实现它们，你会发现你的表现会受到很大的影响。

因为这是CLR的一个属性，所以你是否在F＃中并不重要。我的理解是ML类语言的其他运行时，例如ocaml，没有这个特性，因此可以更频繁地使用异常来控制流程。

Answer 2

  

我的问题是在可用性，性能方面的异常处理中，Option和Exception之间有什么区别？？

option类型提供比异常更强的静态检查，增加了编译器捕获程序员错误的可能性。非异常返回可能比返回Some结果更快，但异常返回比返回None慢几百倍。

  

在哪种情况下使用技术比另一种更好？

每当我编写需要继续运行的服务器和守护进程之类的代码时，我会捕获尽可能多的异常并将其替换为option等联合类型的值。然后，静态类型系统迫使我在几乎所有情况下都处理异常和非异常返回，这使得编写不会因意外传播的异常而死的代码变得更加容易。

Answer 3

从理论的角度来看。 option是你应该在那些纯粹从FP角度看的函数中使用的东西（你可以谷歌关于什么是纯函数）。例外更多的是关于不纯洁的世界（就像Haskell中的IO世界一样）。

现在从实际的角度来看，当你的应用程序的逻辑表明值可以存在或者不能存在时，我建议使用option作为返回类型，即不存在的值是有效的应用程序规则。当应用程序逻辑中发生某些事件时，应该引发异常，这些事件表明逻辑执行不正确或者某些不正确的应用程序状态不符合应用程序规则。

从性能POV抛出异常比返回选项类型更昂贵（由于堆栈展开 - 寻找适当的异常处理程序等）。

Answer 4

在可用性方面，我更喜欢F＃中的选项。

• 选项封装了异常状态以及预期状态。这使您可以 deffer 处理异常状态，直到您需要预期状态。
• 选项还有一些helper functions您必须自己编写例外情况。
• Partial Active Patterns允许您使用选项非常干净地处理多个例外情况。
F＃中的
• Optional Paramaters是使用Options实现的。我上面提到的这种延迟性质使您无需关心产生异常情况的原因，只要消费者具有默认值即可。

选择是一种从根本上不同的思考特殊情况的方式，我相信有助于使F＃特别。