Erlang's(或Joe Armstrong's？)建议100和让进程崩溃(而不是用不必要的卫兵试图跟踪崩溃的情况来污染代码)对我来说非常有意义，现在我想知道为什么这么多年来我在错误处理上浪费了这么多精力！
我想知道的是，这种方法是否只适用于Erlang这样的平台？Erlang有一个VM，它对进程监控树有简单的本机支持，重启进程的速度很快.我应该把我的开发工作(当我不在Erlang世界时)花在重新创建监督树上，而不是让自己陷入顶级异常处理程序、错误代码、空结果等的泥潭中吗.
你认为这种方法的改变会在future 很好地发挥作用吗.NET还是Java空间？
It's applicable everywhere.无论你是否以"让它崩溃"的模式编写软件，它都会崩溃，例如，当硬件出现故障时."让它崩溃"适用于任何你需要承受现实的地方.引用詹姆斯·汉密尔顿的话:
如果硬件故障需要立即采取任何管理措施，该服务就不会以经济高效和可靠的方式进行扩展.在没有人工管理交互的情况下，整个服务必须能够在故障中幸存下来.故障恢复必须是一条非常简单的路径，并且必须经常测试该路径.斯坦福大学的阿曼多·福克斯(Armando Fox)认为，测试故障路径的最佳方式是永远不要正常关闭服务.只是很难让它失败.这听起来有悖常理，但是如果故障路径不经常使用，它们在需要的时候就不会起作用.
不过，这并不意味着"永远不要使用警卫".但不要害怕撞车！