Erlang（或Joe Armstrong的？）建议不要使用防御性编程并让进程崩溃（而不是用不必要的保护人员来污染你的代码，试图跟踪残骸）现在对我来说非常有意义，我想知道为什么多年来我在错误处理上浪费了这么多精力！
我想知道的是 - 这种方法仅适用于像Erlang这样的平台吗？Erlang 有一个 VM，它对进程监督树具有简单的本机支持，重新启动进程的速度非常快。我是否应该将开发工作（不在Erlang世界中）花在重新创建监督树上，而不是让自己陷入顶级异常处理程序，错误代码，空结果等等。
你认为这种方法的改变在（比如）.NET或Java领域会很好地发挥作用吗？
它适用于任何地方。无论你是否以“让它崩溃”的模式编写软件，它无论如何都会崩溃，例如，当硬件出现故障时。“让它崩溃”适用于任何需要承受现实的地方。夸斯·詹姆斯·汉密尔顿：
如果硬件故障需要立即执行任何管理操作，则该服务根本无法经济高效且可靠地进行扩展。整个服务必须能够在没有人工管理交互的情况下幸存故障。故障恢复必须是一个非常简单的路径，并且必须经常测试该路径。斯坦福大学的阿曼多·福克斯（Armando Fox）认为，测试故障路径的最佳方法是永远不要正常关闭服务。只是硬失败它。这听起来有悖常理，但如果故障路径不经常使用，它们将在需要时不起作用。
不过，这并不确切意味着“永远不要使用防护装置”。但不要害怕崩溃！
是的，它适用于任何地方，但重要的是要注意它应该在哪种情况下使用。这并不意味着应用程序作为一个整体崩溃，正如@PeterM指出的那样，在许多情况下可能是灾难性的。目标是构建一个整体永远不会崩溃的系统，但可以在内部处理错误。在我们的例子中，电信系统预计每年会有几分钟的停机时间。
基本设计是将系统分层并隔离系统的中心部分，以监视和控制完成工作的其他部分。在OTP术语中，我们有主管和工人流程。主管的工作是监视工人和其他主管，目的是在工人完成所有实际工作时，以正确的方式重新启动它们。使用这种严格分离功能的原则，在层中正确构建系统，可以将大部分错误处理从工作线程隔离到主管中。您尝试最终得到一个小的故障安全错误内核，如果正确，可以在系统其余部分的任何位置处理错误。正是在这种背景下，“让它崩溃”的哲学应该被使用。
你会得到一个悖论，即你在哪里思考各地的错误和失败，目的是在尽可能少的地方实际处理它们。
处理错误的最佳方法当然取决于错误和系统。有时，最好尝试在进程中本地捕获错误，并尝试在那里处理它们，如果这不起作用，可以选择再次失败。如果您有许多工作进程在合作，那么通常最好将它们全部崩溃并再次重新启动。是主管这样做的。
您确实需要一种语言，当出现问题时会生成错误/异常，以便您可以捕获它们或让它们使进程崩溃。只是忽略错误返回值不是一回事。
