Erlang(或 Joe Armstrong？)的建议不要使用防御性编程并让进程崩溃(而不是用试图跟踪wreckage) 对我来说非常有意义，以至于我想知道为什么多年来我在错误处理上浪费了这么多精力!
我想知道的是——这种方法是否只适用于像 Erlang 这样的平台？ Erlang 有一个虚拟机，它对进程监督树提供简单的原生支持，并且重新启动进程真的很快。我是否应该将我的开发工作(不在 Erlang 世界中时)花在重新创建监督树上，而不是让自己陷入顶级异常处理程序、错误代码、空结果等等等。
您认为这种方法的改变在(比如说).NET 或 Java 领域会很好用吗？
最佳答案
It's applicable everywhere .无论您是否以“让它崩溃”模式编写软件，它都会崩溃，例如，当硬件发生故障时。 “让它崩溃”适用于您需要承受现实的任何地方。詹姆斯·汉密尔顿:
If a hardware failure requires any immediate administrative action, the service simply won’t scale cost-effectively and reliably. The entire service must be capable of surviving failure without human administrative interaction. Failure recovery must be a very simple path and that path must be tested frequently. Armando Fox of Stanford has argued that the best way to test the failure path is never to shut the service down normally. Just hard-fail it. This sounds counter-intuitive, but if the failure paths aren’t frequently used, they won’t work when needed.
但这并不完全意味着“从不使用 guard ”。但不要害怕崩溃!
关于java - Erlang 的让它崩溃的哲学 - 适用于其他地方吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4393197/