Erlang的让它崩溃的哲学 – 适用于其他地方？
Erlang（或者Joe Armstrong的？）build议不要使用防御性编程 ，而是让进程崩溃（而不是用不必要的守卫来跟踪残骸，污染你的代码）对我来说非常有意义，现在我想知道为什么我浪费了这么多努力处理多年的error handling！
我想知道的是 – 这种方法只适用于像Erlang这样的平台吗？ Erlang拥有一个虚拟机，对进程监督树进行简单的本机支持，重启进程非常快。 我应该把我的开发工作（不在Erlang世界）花在重build监督树上，而不是用顶层exception处理程序，错误代码，空结果等等让自己陷入困境。
你认为这种方法的改变在.NET或者Java的空间（比如说）中可以运行吗？
它适用于任何地方 。 无论您是否将软件写入“让其崩溃”模式，它都会崩溃，例如硬件出现故障时。 “让它崩溃”适用于任何需要抵御现实的地方。 Quoth James Hamilton：
如果硬件故障需要立即采取行政行动，则服务不会经济有效地进行可靠的扩展。 整个服务必须能够在没有人为pipe理的情况下幸免于难。 故障恢复必须是一个非常简单的path，并且该path必须经常testing。 斯坦福大学的阿曼多·福克斯（Armando Fox）认为，testing失败path的最好方法是永远不要closures服务。 只是很难 – 失败。 这听起来是违反直觉的，但是如果故障path不经常使用，则在需要时它们将不起作用。
不过，这并不意味着“从不使用警卫”。 但是不要害怕崩溃！
是的，它适用于任何地方，但重要的是要注意在哪个上下文中使用它。 这并不意味着整个应用程序崩溃，正如@PeterM指出的那样，在很多情况下可能是灾难性的。 目标是build立一个整体系统从不崩溃，但可以在内部处理错误。 在我们的情况下，电信系统预计每年会有几分钟的停机时间。
其基本devise是对系统进行分层，隔离系统的中心部分，以监视和控制执行工作的其他部分。 在OTP术语中，我们有主pipe和工作stream程。 监事有监督职工和其他监督人员的工作，其目标是在工作人员全部实际工作时，以正确方式重新启动。 使用严格分离function的原则，正确地分层构build系统，可以将工作人员的大部分error handling隔离到主pipe。 你试图最终得到一个小的故障安全错误内核，如果它正确的话可以处理系统其余部分的任何地方的错误。 正是在这种情况下，“让它崩溃”的哲学才被使用。
你会得到一个悖论，就是你在哪里想到错误和失败的地方，以便在尽可能less的地方实际处理它们。
如何最好地处理错误当然取决于错误和系统。 有时候最好在stream程中尝试在本地捕获错误，并尝试在那里处理错误，如果失败，可以select再次失败。 如果你有一些工作进程协作，那么通常最好把它们全部崩溃，然后重新启动它们。 这是一个主pipe这样做。
当出现错误时，您需要一种能够生成错误/exception的语言，这样您就可以捕获错误或exception，从而使错误/exception崩溃。 只是忽略错误返回值是不一样的。
它被称为快速失败。 这是一个很好的范例，只要你有一个能够对失败做出反应的人（而且这样做很快）。
在NAVY中，所有的pipe道和电气安装在墙的外部（最好在墙的更公共的一面）。 那样的话，如果有泄漏或者问题的话，就很有可能被迅速的检测出来。 在NAVY中，人们因为没有对失败做出反应而受到惩罚，因此工作得很好：快速发现失败并迅速采取行动。
在某个人不能快速采取行动的情况下，让失败停止系统或吞下失败并继续前进是更有利的问题。
我写的程序依赖于来自现实世界的数据，如果他们崩溃，他们可能会造成巨大的物理损失（更不用说大损失的收入）。 如果我没有在防守方面进行编程，我会在一瞬间失去工作。
说到这一点，我认为Erlang一定是一个特例，你不仅可以立即重启，重启的程序可以popup来，环顾四周，说“啊，那就是我正在做的！
我的同事和我自己想的不是特别技术上的问题，而是从领域和安全的angular度来看。
问题是“让它崩溃是安全的吗？” 或更好的“甚至有可能像Erlang的”让它崩溃“一样适用于安全相关的软件项目？
为了find答案，我们做了一个小型的研究项目，采用了接近现实的scheme，具有工业特别是医学背景。 看看这里（ http://bit.ly/Z-Blog_let-it-crash ）。 甚至有一个文件下载。 告诉我你的想法！
我个人认为这在许多情况下是适用的，甚至是可取的，特别是当有大量的error handling（安全相关的系统）时。 你不能总是使用Erlang（缺less实时特性，没有真正的embedded式支持，消费者喜欢…），但我敢肯定，你可以实现，否则（例如使用线程，exception，消息传递）。 我还没有尝试过，但我想。
恕我直言，一些开发人员处理/包装检查exception与代码，增值一点。 除非要处理它并添加一些值，否则允许方法抛出原始exception通常更简单。
