java - elm 的编译与 Java 的检查异常有何不同？

Question

elm 对 zero-runtime-exceptions 的声明是其主要卖点之一(参见 official website )，

但如果您停下来想一想，没有什么能阻止您被零除或内存不足。

elm 编译器的基本功能是强制您覆盖所有可能导致异常的路径。

例如:

import String exposing (toInt)
toIntOrZero s = case toInt s of
                          Err e -> 0
                          Ok val -> val

但这与 infamous 有何不同？ java 中的“检查异常”功能？

public static Integer toIntOrZero(String s) {
    try { return Integer.valueOf(s); }
    catch (NumberFormatException e) { return 0; }
}

我从来没有听说过任何人声称 java 是一种零运行时异常语言。

Answer 1

请不要太在意什么本质上是营销夸张。 当然有些错误是您永远无法用任何编译器完全排除的。

因此，我一直对这些零运行时异常声明持保留态度，但我想我理解支持者的意图。 Elm 的创建是为了替代使用 Javascript 开发前端应用程序，这是一个困惑的世界，异常比比皆是，只是日常生活的一部分。 Elm 使搬起石头砸自己的脚更难，并且无需太多努力，如果您对应用程序进行基本的健全性测试，您可能不会在生产中遇到运行时异常 .

Elm 在几个方面极大地降低了异常的可能性。

1. 除了 Debug.crash 之外，语言中没有可抛出异常的概念，顾名思义，它实际上应该只用于调试和清除不完整的逻辑路径.

   由于没有可抛出的异常，处理问题通常通过 Result 和 Maybe 等类型来完成。

   这可以被认为与 Java 的已检查异常大致相似，但从概念上讲，它们与我感觉非常不同。面对现实吧。异常被滥用了。您提到了 Java 中的一个示例，其中 Integer.valueOf() 表示它将返回一个 int，但如果您向它传递任何其他内容，它会展开堆栈并向上冒泡，直到某个函数有望捕获它.这对我来说感觉非常困惑，当然，检查异常可以帮助减少故障传播的窗口，但潜在的事实是异常是业务逻辑的错误工具。

   抛出异常的替代方法是使用类似于 Result 和 Maybe Elm 类型的类，但这在早期的 Java 中几乎是不可能的干净地做，即使使用泛型，编写这样的类型也比 Elm 类型的简单性更乏味且更容易出错。而且由于 Elm 的封闭类型系统，

2. 非穷举模式匹配导致编译失败

   在 Java 和 Javascript 中，无法进行详尽的模式匹配检查，因为类型系统不允许这样做。当然，Typescript 引入了一些功能，但你必须选择加入它。在 Elm 中，您必须显式处理所有情况。当然，我想您可能会争辩说，Elm 让您通过以包罗万象的 _ 结束所有 case 语句来选择退出详尽的模式匹配，但这只是对语言的愚蠢滥用。这些检查可以为您提供帮助，而且我没有选择加入 Elm 中的错误检查这一事实让我感到更加安全 - 默认情况下它就在那里!

3. 不变性

   不可变性避免了大量潜在的错误类型，这里无法一一列举。

4. Elm 架构在 Javascript 和 Elm 之间提供了清晰的分离

   Elm 可以编译成 Javascript，但 Elm 架构提供了一个很好的干净屏障，使所有讨厌的 Javascript 位远离 Elm 编写的纯代码。 Javascript 中可能发生的任何异常都应由该屏障处理，这样 I/O 错误将始终被转换为 Elm 友好的无异常类型。

最后，运行时异常仍然是可能的(例子:next tagged Elm question 处理了一个众所周知的由递归 JSON 解码器定义引起的运行时异常)，每当我听到有人说这是不可能在 Elm 中获得异常。事实上，异常是可能的，但几乎所有您在日常 Javascript 开发中遇到的异常在 Elm 中本质上都是不可能的。