像Elm所说的那样，拥有“没有运行时异常”有什么好处？

某些语言声称具有“无运行时异常”，这是与具有它们的其他语言相比的明显优势。

我对此事感到困惑。

据我所知，运行时异常只是一种工具，使用得当：

• 您可以传达“脏”状态（抛出意外数据）
• 添加堆栈，您可以指向错误链
• 您可以区分混乱（例如，在无效输入上返回空值）和需要开发人员注意的不安全用法（例如，在无效输入上引发异常）
• 您可以通过异常消息为错误添加详细信息，从而提供进一步有用的详细信息，以帮助调试（理论上）

另一方面，我发现很难调试“吞噬”异常的软件。例如

try { 
  myFailingCode(); 
} catch {
  // no logs, no crashes, just a dirty state
}

因此，问题是：拥有“无运行时异常”的强大的理论优势是什么？

例

https://guide.elm-lang.org/

实际上没有运行时错误。没有空值。没有未定义不是函数。

异常具有极其有限的语义。必须精确地将它们扔到什么地方，或向上直接调用堆栈中进行处理，并且如果您忘记这样做，则在编译时没有向程序员的指示。

与Elm对比，其中Elm将错误编码为Results或Maybes，它们都是值。这意味着如果不处理该错误，则会出现编译器错误。您可以将它们存储在变量甚至集合中，以将它们的处理推迟到方便的时间。您可以创建一个函数来以特定于应用程序的方式处理错误，而不是到处重复非常相似的try-catch块。您可以将它们链接到一个仅在所有部分都成功的情况下才能成功的计算中，而不必将它们塞满一个try块。您不受内置语法的限制。

这与“吞下异常”完全不同。它使错误条件在类型系统中变得明确，并提供了更灵活的替代语义来处理它们。

考虑以下示例。如果您希望看到它的实际效果，可以将其粘贴到http://elm-lang.org/try中。

import Html exposing (Html, Attribute, beginnerProgram, text, div, input)
import Html.Attributes exposing (..)
import Html.Events exposing (onInput)
import String

main =
  beginnerProgram { model = "", view = view, update = update }

-- UPDATE

type Msg = NewContent String

update (NewContent content) oldContent =
  content

getDefault = Result.withDefault "Please enter an integer" 

double = Result.map (\x -> x*2)

calculate = String.toInt >> double >> Result.map toString >> getDefault

-- VIEW

view content =
  div []
    [ input [ placeholder "Number to double", onInput NewContent, myStyle ] []
    , div [ myStyle ] [ text (calculate content) ]
    ]

myStyle =
  style
    [ ("width", "100%")
    , ("height", "40px")
    , ("padding", "10px 0")
    , ("font-size", "2em")
    , ("text-align", "center")
    ]

请注意，String.toInt在calculate函数有失败的可能。在Java中，这有可能引发运行时异常。在读取用户输入时，它有很大的机会。Elm而是通过返回a来迫使我处理它Result，但是请注意，我不必立即处理它。我可以将输入加倍并将其转换为字符串，然后检查getDefault函数中是否有错误的输入。该位置比发生错误的位置或调用堆栈中向上的位置更适合进行检查。

与Java的检查异常相比，编译器强制我们执行操作的方式也要细得多。您需要使用非常具体的功能，例如Result.withDefault提取所需的值。从技术上讲，您可能会滥用这种机制，但没有多大意义。由于您可以将决定推迟到知道正确的默认/错误消息后再进行，因此没有理由不使用它。

为了理解此声明，我们首先必须了解静态类型系统向我们购买了什么。本质上，静态类型系统为我们提供了保证：如果检查程序类型，则不会发生某些类的运行时行为。

听起来不祥。好吧，类型检查器类似于定理检查器。（实际上，根据Curry-Howard-Isomorphism，它们是同一回事。）关于定理的一件事很奇特的事情是，当您证明一个定理时，您便证明了该定理的确切含义，而已。（例如，这就是为什么当有人说“我已经证明该程序正确”时，您应该始终询问“请定义'正确'”。）类型系统也是如此。当我们说“程序是类型安全的”时，我们的意思不是说不可能发生任何错误。我们只能说类型系统向我们承诺要防止的错误不会发生。

因此，程序可以具有无限多种不同的运行时行为。其中，无数个有用，但无数个“不正确”（对于“正确性”的各种定义）。静态类型系统使我们能够证明不会发生那些无限多个错误的运行时行为的某个有限的固定集合。

基本上，不同类型的系统之间的区别在于，可以证明它们不会发生，多少个以及多么复杂的运行时行为。诸如Java之类的弱类型系统只能证明非常基础的东西。例如，Java可以证明类型为返回a的String方法不能返回a List。但是，例如，它不能证明该方法不会返回。也不能证明该方法不会引发异常。它不能证明它不会返回错误 String  -任何String类型都可以满足类型检查器的要求。（当然，即使null将满足它。）甚至有很简单的事情，Java的不能证明，这就是为什么我们有例外，例如ArrayStoreException，ClassCastException或者大家的喜爱，NullPointerException。

像Agda这样的更强大的类型系统也可以证明诸如“将返回两个参数之和”或“返回作为参数传递的列表的排序版本”之类的东西。

现在，Elm的设计者所声明的他们没有运行时异常的意思是，Elm的类型系统可以证明缺少（大部分）运行时行为，而其他语言无法证明这种运行时行为不会发生，因此可能导致到运行时的错误行为（最好的情况是异常，更坏的情况是崩溃，最坏的情况是没有崩溃，没有异常，只是一个默默的错误结果）。

因此，他们并不是说“我们不实施例外”。他们说：“在Elm中，典型的程序员可能会遇到的典型语言中的运行时异常事件将被类型系统捕获”。当然，来自Idris，Agda，Guru，Epigram，Isabelle / HOL，Coq或类似语言的人会发现Elm相形之下比较弱。该语句更针对典型的Java，C ++，C ++，Objective-C，PHP，ECMAScript，Python，Ruby，Perl等语言。

出于相同的原因，Elm不能保证没有运行时异常。C可以保证没有运行时异常：该语言不支持异常的概念。

Elm有一种在运行时发信号通知错误情况的方法，但是该系统也不例外，它是“结果”。可能失败的函数将返回“结果”，其中包含常规值或错误。Elms是强类型的，因此这在类型系统中是显式的。如果函数始终返回整数，则其类型为Int。但是，如果返回整数或失败，则返回类型为Result Error Int。（字符串是错误消息。）这将强制您在呼叫站点处显式处理这两种情况。

这是引言中的一个示例（有点简化）：

view : String -> String 
view userInputAge =
  case String.toInt userInputAge of
    Err msg ->
        text "Not a valid number!"

    Ok age ->
        text "OK!"

toInt如果输入不可解析，则该函数可能会失败，因此其返回类型为Result String int。要获得实际的整数值，您必须通过模式匹配来“解压缩”，这又迫使您处理这两种情况。

结果和异常从根本上做同样的事情，重要的区别是“默认值”。默认情况下，异常会冒出气泡并终止程序，并且如果要处理它们，则必须明确捕获它们。结果是另一种方式-默认情况下您被迫处理它们，因此如果要它们终止程序，则必须将它们一直传递到顶部。很容易看出这种行为如何导致更健壮的代码。

首先，请注意，您的“吞咽”异常示例通常是一种可怕的做法，并且与没有运行时异常完全无关。当您考虑它时，确实有一个运行时错误，但是您选择隐藏它而不对其进行任何操作。这通常会导致难以理解的错误。

可以以多种方式解释这个问题，但是由于您在注释中提到了Elm，因此上下文更加清晰。

Elm是一种静态类型的编程语言。这种类型的系统的好处之一是，在实际使用程序之前，编译器会捕获许多错误类别（尽管不是全部）。可以将某些类型的错误编码为类型（例如Elm Result和Task），而不是将其抛出异常。这就是Elm的设计者的意思：许多错误将在编译时而不是在“运行时”被捕获，并且编译器将迫使您处理它们，而不是忽略它们并希望获得最佳结果。很明显为什么这是一个优点：更好的是程序员在用户意识到之前就意识到了问题。

请注意，当您不使用异常时，错误会以其他不太令人惊讶的方式编码。根据Elm的文档：

Elm的保证之一是在实践中您不会看到运行时错误。NoRedInk在生产中已经使用Elm大约一年了，但他们仍然没有！像Elm中的所有保证一样，这取决于基本的语言设计选择。在这种情况下，Elm将错误视为数据这一事实为我们提供了帮助。（您是否注意到我们在这里处理了很多数据？）

榆木设计师在主张“无运行时例外”方面有些大胆，尽管他们将其“实际”加以限定。他们可能的意思是“比使用JavaScript进行编码要少的意外错误”。

榆树声称：

实际上没有运行时错误。没有空值。没有未定义不是函数。

但是您会询问运行时异常。有区别。

在榆树中，没有任何东西会返回意外结果。您不能在Elm中编写会导致运行时错误的有效程序。因此，您不需要例外。

因此，问题应该是：

“没有运行时错误”有什么好处？

如果您可以编写永远不会出现运行时错误的代码，则程序将永远不会崩溃。