Erlang的Let-it-crash哲学 - 适用于其他地方?

2022-08-31 14:01:57

Erlang(或Joe Armstrong的?)建议不要使用防御性编程并让进程崩溃(而不是用不必要的保护人员来污染你的代码,试图跟踪残骸)现在对我来说非常有意义,我想知道为什么多年来我在错误处理上浪费了这么多精力!

我想知道的是 - 这种方法仅适用于像Erlang这样的平台吗?Erlang 有一个 VM,它对进程监督树具有简单的本机支持,重新启动进程的速度非常快。我是否应该将开发工作(不在Erlang世界中)花在重新创建监督树上,而不是让自己陷入顶级异常处理程序,错误代码,空结果等等。

你认为这种方法的改变在(比如).NET或Java领域会很好地发挥作用吗?


答案 1

它适用于任何地方。无论你是否以“让它崩溃”的模式编写软件,它无论如何都会崩溃,例如,当硬件出现故障时。“让它崩溃”适用于任何需要承受现实的地方。夸斯·詹姆斯·汉密尔顿:

如果硬件故障需要立即执行任何管理操作,则该服务根本无法经济高效且可靠地进行扩展。整个服务必须能够在没有人工管理交互的情况下幸存故障。故障恢复必须是一个非常简单的路径,并且必须经常测试该路径。斯坦福大学的阿曼多·福克斯(Armando Fox)认为,测试故障路径的最佳方法是永远不要正常关闭服务。只是硬失败它。这听起来有悖常理,但如果故障路径不经常使用,它们将在需要时不起作用。

不过,这并不确切意味着“永远不要使用防护装置”。但不要害怕崩溃!


答案 2

是的,它适用于任何地方,但重要的是要注意它应该在哪种情况下使用。这并不意味着应用程序作为一个整体崩溃,正如@PeterM指出的那样,在许多情况下可能是灾难性的。目标是构建一个整体永远不会崩溃的系统,但可以在内部处理错误。在我们的例子中,电信系统预计每年会有几分钟的停机时间。

基本设计是将系统分层并隔离系统的中心部分,以监视和控制完成工作的其他部分。在OTP术语中,我们有主管工人流程。主管的工作是监视工人和其他主管,目的是在工人完成所有实际工作时,以正确的方式重新启动它们。使用这种严格分离功能的原则,在层中正确构建系统,可以将大部分错误处理从工作线程隔离到主管中。您尝试最终得到一个小的故障安全错误内核,如果正确,可以在系统其余部分的任何位置处理错误。正是在这种背景下,“让它崩溃”的哲学应该被使用。

你会得到一个悖论,即你在哪里思考各地的错误和失败,目的是在尽可能少的地方实际处理它们。

处理错误的最佳方法当然取决于错误和系统。有时,最好尝试在进程中本地捕获错误,并尝试在那里处理它们,如果这不起作用,可以选择再次失败。如果您有许多工作进程在合作,那么通常最好将它们全部崩溃并再次重新启动。是主管这样做的。

您确实需要一种语言,当出现问题时会生成错误/异常,以便您可以捕获它们或让它们使进程崩溃。只是忽略错误返回值不是一回事。


推荐