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通常更简单。