[java] Erlang的let-it-crash理念 - 适用于其他地方?



Answers

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

基本设计是将系统分层并隔离系统的中心部分,以监视和控制执行工作的其他部分。 在OTP术语中,我们有主管工人流程。 监督员负责监督工人和其他监督员,目的是在工人完成所有实际工作时以正确的方式重新启动工人。 使用严格分离功能的原则在层中正确地构建系统允许您将大多数错误处理从工作者中隔离到监督者中。 您尝试最终得到一个小的故障安全错误内核,如果正确可以处理系统其余部分的任何错误。 正是在这种情况下,才意味着使用“让它崩溃”的理念。

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

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

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

Question

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

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

您是否认为这种方法的改变在(或者说).NET或Java空间中运行良好?




恕我直言一些开发人员处理/包装已检查的异常与代码几乎没有价值。 允许方法抛出原始异常通常更简单,除非您要处理它并添加一些值。




它被称为失败快速。 这是一个很好的范例,只要你有一个能够应对失败的团队(并且快速做到这一点)。

在NAVY中,所有管道和电气都安装在墙壁的外部(最好是在墙壁的公共侧面)。 这样,如果存在泄漏或问题,则更有可能快速检测到。 在NAVY中,人们因没有对故障做出反应而受到惩罚,因此它运作良好:快速检测到故障并迅速采取行动。

在某人无法快速对失败采取行动的情况下,让失败停止系统或吞下失败并尝试继续前进是否更为有益。






Links