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

Question

elm 对 zero-runtime-exceptions is one of its major selling point (see official website 的声明),

但是如果你停下来想一想，没有什么能阻止你除以零或运行内存不足。

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

例如：

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

但这与 java 中的 infamous "checked-exceptions" 功能有何不同？

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

我从未听说 java 是一种零运行时异常语言。

Answer 1

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

因此，我一直对这些零运行时间异常的说法持保留态度，但我想我理解支持者的意图。 Elm 是作为在 Javascript 中开发前端应用程序的替代方法而创建的，这是一个混乱的世界，异常比比皆是，只是日常生活的一部分。 Elm 让搬起石头砸自己的脚更难，如果你运行通过对你的应用程序进行基本的健全性测试，你可能不会没有太多的努力运行生产中时间异常。

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

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

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

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

抛出异常的另一种方法是让类类似于 Result 和 Maybe Elm 类型，但这在类的早期几乎是不可能的=65=] 做的干净利落，即使使用泛型，编写这样的类型也比 Elm 类型的简单性更乏味且更容易出错。而且由于 Elm 的封闭类型系统，
非穷举模式匹配导致编译失败

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

不可变性避免了大量潜在的错误类型，这里无法一一列举。
Elm 架构在 Javascript 和 Elm
之间提供了清晰的分离
Elm 编译成 Javascript，但 Elm 架构提供了一个很好的干净屏障，使 Javascript 的所有讨厌的部分远离 Elm 编写的纯代码。 Java脚本中可能发生的任何异常都应由该屏障处理，这样 I/O 错误将始终被转换为 Elm 友好的无异常类型。

最后，运行时间异常仍然是可能的（例子：next tagged Elm question 处理了由递归 JSON 解码器定义），每当我听到有人说在 Elm 中不可能获得异常时，我都会有点畏缩。事实上，例外是可能的，但几乎所有您在日常 Java 脚本开发中运行遇到的例外都是 本质上 不可能的在榆树。

Answer 2

正如评论者指出的那样，Java 存在未经检查的异常，因此会发生运行时错误 do。 Elm 也有未经检查的异常，例如被零除之类的异常，但去掉了实践中最常见的异常。正如 Chad 的回答所提到的，Elm 的 Maybe/Result 类型在实践中的工作方式与 Java 的已检查异常有很大不同。经验丰富的 Elm 程序员不会编写像 toIntOrZero 这样的函数（如果他们这样做了，他们可能不会使用 case ... of，而是更喜欢像 toIntOrZero = String.toInt >> Result.withDefault 0 这样的函数）。

将多个操作与 Result.map、Result.andThen 等链接在一起，提供了一种处理错误情况的非常有表现力的方式，而不会迫使程序员深入了解杂草。例如，如果我们想编写一个函数，通过将 ID 转换为 Int 来验证 ID，在某些数据结构中查找它（当它可能不存在时），然后验证与该用户关联的一些属性，我们可以这样写：

lookupUser : Int -> Result String User
lookupUser intId = ...

userInGoodStanding : User -> Bool
userInGoodStanding user = ...

isValidId : String -> Bool
isValidId id = 
  String.toInt id 
  |> Result.andThen lookupUser 
  |> Result.map userInGoodStanding
  |> Result.withDefault False

上面写着，"convert the ID to an int, then look up the associated user, then verify the user, and if anything failed, return False."你的里程可能会有所不同，但一旦你习惯了它，我（和许多 Elm 程序员，我想！）发现这是一种非常好的编写健壮代码的方法错误。

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

How does elm's compilation differ from Java's checked exceptions?

java

elm

checked-exceptions