本章涵盖

• 运行时错误
• 并发系统中的错误
• 监督者

容错是 BEAM 中的一流概念。开发能够在运行时错误面前仍然能够操作的可靠系统的能力正是我们最初引入 Erlang 的原因。

容错的目的是承认故障的存在，最小化其影响，并最终在没有人工干预的情况下恢复。在一个足够复杂的系统中，许多事情可能会出错。偶尔会发生错误，您依赖的组件可能会失败，您可能会遇到硬件故障。系统也可能会过载，无法应对增加的请求速率。最后，如果系统是分布式的，您可能会遇到额外的问题，例如远程机器变得不可用，可能是由于崩溃或网络连接中断。

很难预测所有可能出错的情况，因此面对任何事情都可能失败的严酷现实更为明智。无论系统的哪个部分发生故障，都不应该导致整个系统崩溃；你希望至少能够提供一些服务。例如，如果数据库服务器无法访问，你仍然可以从缓存中提供数据。你甚至可以将传入的存储请求排队，并在与数据库的连接恢复后尝试解决它们。

您还必须检测故障并尝试从中恢复。在前面的例子中，系统可能会尝试重新连接到数据库，直到成功为止，然后恢复提供完整服务。

这些是一个具有弹性和自愈能力系统的特性。无论发生什么问题（请记住，任何事情都有可能出错），系统应尽可能提供服务，并尽快完全恢复。

这种思维显著改变了错误处理的方法。与其执着于减少错误的数量，不如优先考虑最小化它们的影响并自动恢复。在一个必须持续运行的系统中，经历许多孤立的错误比遇到一个导致整个系统崩溃的错误要好。

有点令人惊讶的是，错误处理的核心工具是并发。在 BEAM 世界中，两个并发进程是完全独立的；它们不共享内存，一个进程的崩溃默认情况下不会影响另一个进程的执行流程。进程隔离使您能够将错误的负面影响限制在单个进程或一小组相关进程中，从而使大部分系统正常运行。

当然，当一个进程崩溃时，您通常会想要检测这种状态并采取措施。在本章中，您将学习在并发系统中检测和处理错误的基本技术。然后，在第 9 章中，您将扩展这些知识并实现细粒度的错误隔离。让我们先从一些关于运行时错误的理论开始。

8.1 运行时错误

在前面的章节中，我大致提到在各种情况下会引发错误。最常见的例子之一是模式匹配失败。如果匹配失败，则会引发错误。另一个例子是同步 GenServer.call 。如果响应消息在给定的时间间隔内（默认 5 秒）没有到达，则会发生运行时错误。还有许多其他例子，例如无效的算术操作（例如，除以零）、调用不存在的函数以及显式错误信号。

当运行时错误发生时，执行控制被转移到调用栈上的错误处理代码。如果您没有指定这样的代码，则发生错误的进程将被终止。默认情况下，所有其他进程不受影响地运行。

8.1.1 错误类型

BEAM 区分三种运行时错误：错误、退出和抛出。以下是一些典型的错误示例：

iex(1)> 1/0                                         ?
** (ArithmeticError) bad argument in arithmetic expression
 
iex(1)> Module.nonexistent_function()               ?
** (UndefinedFunctionError) function Module.nonexistent_function/0 is
   undefined or private
 
iex(1)> List.first({1,2,3})                         ?
** (FunctionClauseError) no function clause matching in List.first/2

? 无效的算术表达式

? 调用不存在的函数

? 模式匹配错误

您还可以通过使用 raise/1 宏来引发自己的错误，传递错误字符串：

iex(1)> raise("Something went wrong")
** (RuntimeError) Something went wrong

如果您的函数明确引发错误，您应该在其名称后附加 ! 字符。这是 Elixir 标准库中使用的约定。例如， File.open! 如果无法打开文件则引发错误：

iex(1)> File.open!("nonexistent_file")
** (File.Error) could not open non_existing_file: no such file or directory

相反， File.open （注意缺少 ! ）仅返回文件无法打开的信息：

iex(1)> File.open("nonexistent_file")
{:error, :enoent}

请注意，在这个代码片段中，没有运行时错误。 File.open 返回一个结果，调用者可以以某种方式处理它。

另一种运行时错误是退出，它用于故意终止一个进程。要退出当前进程，可以调用 exit/1 ，并提供退出原因：

iex(2)> spawn(fn ->
          exit("I'm done")                  ?
          IO.puts("This doesn't happen")
        end)

? 退出当前进程

退出原因是一个任意术语，用于描述您终止该过程的原因。正如您稍后将看到的，某些其他进程可以检测到进程崩溃并获取此退出原因。

最终的运行时错误类型是抛出。要发出抛出，可以调用 throw/1 :

iex(3)> throw(:thrown_value)
** (throw) :thrown_value

抛出操作的目的是允许非本地返回。正如你在第 3 章和第 4 章中看到的，Elixir 程序组织在许多嵌套的函数调用中。特别是，循环是通过递归实现的。结果是没有像 break 、 continue 和 return 这样的结构，你可能在其他语言中见过。当你深陷循环时，停止循环并返回一个值并不是一件简单的事情；抛出操作可以帮助解决这个问题。你可以抛出一个值并在调用栈中捕获它。但是，将抛出操作用于控制流是比较 hacky 的，并且有点像 goto ，你应该尽量避免这种技术。

8.1.2 处理错误

当然，可以拦截任何类型的运行时错误（错误、退出或抛出）并对此采取措施。主要的工具是 try 表达式。以下是如何运行一些代码并捕获错误：

try do
  ...
catch error_type, error_value ->
  ...
end

这与您可能在其他语言中看到的非常相似。 do 块中的代码被执行，如果发生错误，执行将转移到 catch 块。

注意在 catch 中指定了两件事。 error_type 将包含一个原子 :error 、 :exit 或 :throw ，指示发生的错误类型。 error_value 将包含特定于错误的信息，例如被抛出的值或引发的错误。

让我们通过编写一个辅助的 lambda 来玩一下这个，以便更容易地实验错误：

iex(1)> try_helper = fn fun ->
          try do
            fun.()
            IO.puts("No error.")
 
          catch type, value ->
            IO.puts("""
              Error
                #{inspect(type)}
                #{inspect(value)}
              """)
          end
        end

这个辅助 lambda 以一个函数作为参数，在 try 中调用该函数，并报告错误类型及相应的值。由于输出跨越多行，因此使用了 heredoc 语法 ( """ )，在第二章中已简要提及。

让我们试试看：

iex(2)> try_helper.(fn -> raise("Something went wrong") end)
Error
  :error                                            ?
  %RuntimeError{message: "Something went wrong"}    ?

? 错误类型

? 错误值

注意字符串消息是如何被包裹在 RuntimeError 结构中的。这是一个特定于 Elixir 的装饰，来自 raise/1 宏内部。如果您想引发一个普通的、未装饰的错误，可以使用 Erlang 的 :erlang.error/1 并提供一个任意的术语。结果错误值将是您引发的术语。

如果您尝试抛出一个值，您将获得不同的错误类型：

iex(3)> try_helper.(fn -> throw("Thrown value") end)
Error
  :throw
  "Thrown value"

调用 exit/1 产生不同类型：

iex(4)> try_helper.(fn -> exit("I'm done") end)
Error
  :exit
  "I'm done"

请记住，在 Elixir 中，一切都是有返回值的表达式。使用 try 时，返回值是最后执行的表达式的结果——要么来自 do 块，要么如果引发了错误，则来自 catch 块：

iex(5)> result =
          try do
            throw("Thrown value")
          catch type, value -> {type, value}
          end
 
iex(6)> result
{:throw, "Thrown value"}

值得注意的是，在 catch 块中指定的 type 和 value 是模式。如果您想处理特定类型的错误，可以通过提供相应的模式来实现。

例如，假设您想立即从深层嵌套循环内部返回一个值。您可以调用以下内容：

throw({:result, some_result})

然后，在调用栈的某个地方，您将处理这个抛出：

try do
  ...
catch
  :throw, {:result, x} -> x
end

在这个例子中，您只匹配特定的运行时错误：以 {:result, x} 形式抛出的错误。如果抛出其他任何内容，您将无法捕获它，错误将进一步向上传播到调用栈。如果错误未被处理，进程将终止。

因为 catch 是一个模式匹配，可以指定多个子句，就像您在 case 和 receive 表达式中看到的那样：

try do
  ...
 
catch
  type_pattern_1, error_value_1 ->
    ...
 
  type_pattern_2, error_value_2 ->
    ...
 
  ...
end

在第一个匹配到的引发错误的模式下，调用该块，并返回最后一个表达式的结果。

如果您想捕获任何内容，可以使用 type, value 模式，或者如果您对值不感兴趣，可以使用 _, _ 。这些模式将处理可能发生的任何错误。

也可以指定在 try 块之后始终执行的代码，无论是否引发了错误：

iex(7)> try do
          raise("Something went wrong")
        catch
          _,_ -> IO.puts("Error caught")
        after
          IO.puts("Cleanup code")    ?
        end
 
Error caught
Cleanup code

? 始终执行

因为它总是被执行， after 块对于清理资源非常有用——例如，关闭一个打开的文件。

值得注意的是， after 子句不会影响整个 try 表达式的结果。 try 的结果是最后一个表达式的结果，来自 do 块或如果捕获了某些内容，则来自相应的 catch 块。

尝试和尾调用

您可能还记得第 3 章中的尾调用优化。如果一个函数的最后一件事是调用另一个函数（或它自己），那么将会发生简单的跳转，而不会进行栈推送。如果函数调用位于 try 表达式中，则无法进行此优化。这是相当明显的，因为一个函数的最后一件事是一个 try 块，并且在其 do 或 catch 块完成之前，它不会结束。因此，在 try 中调用的任何内容都不是函数的最后一件事，因此不适合进行尾调用优化。

信号和处理运行时错误的内容远不止这些。Elixir 在这个基本机制之上提供了一些抽象。您可以通过 defexception 宏定义自定义错误（请参见 https://hexdocs.pm/elixir/Kernel.xhtml#defexception/1），并以稍微优雅的方式处理它们。 try 特殊形式还有一些我们尚未讨论的其他功能。您绝对应该研究官方 try 文档（https://hexdocs.pm/elixir/Kernel.SpecialForms.xhtml#try/1）以及相应的“入门”部分（https://elixir-lang.org/getting-started/try-catch-and-rescue.xhtml）。

我在这里展示的是运行时错误的核心概念。Elixir 支持的所有其他扩展最终都归结为这些概念，并具有相同的属性：

• 运行时错误有一个类型，可以是 :error 、 :exit 或 :throw 。
• 运行时错误也有一个值，可以是任何任意术语。
• 如果未处理运行时错误，相应的进程将终止。

与 C++、C#、Java 和 JavaScript 等语言相比，捕获运行时错误的需求要小得多。更常见的做法是让进程崩溃，然后采取措施（通常是重启进程）。这种方法可能看起来有些黑客，但背后是有原因的。在复杂系统中，大多数错误在测试阶段就被排除。剩下的错误大多属于所谓的海森堡错误——在特殊情况下不规律发生且难以重现的不可预测错误。这类错误的原因通常在于状态的损坏。因此，合理的补救措施是让进程崩溃并启动另一个进程。

这可能有帮助，因为您正在摆脱进程状态（可能已损坏）并从干净的状态开始。在许多情况下，这样做可以解决当前的问题。当然，错误应该被记录下来，以便您可以稍后分析并检测根本原因。但在此期间，您可以从意外故障中恢复并继续提供服务。

不要担心如果这个讨论看起来模糊。这种错误处理方法，也称为让它崩溃，将在本章和下一章中详细解释。在接下来的部分中，我们将探讨并发系统中错误处理的基础知识。