该崩溃的时候就崩溃吧，至少写程序应该是这样

图片：Yestone.com 版权图片库

应该如何理解 Erlang 的「任其崩溃」思想？

程墨Morgan，互联网产品开发老兵，《深入浅出React和Redux》作者

“就让它崩溃”（Let it Crash）这个思想很好，不过这个思想和 Erlang 没有什么直接关系，这个思想适用于任何一种语言、任何一种平台、任何一种服务。

很多年前，我第一次听到这个观念，是在微软去上 Jeff Richter 讲 C#的课，Jeff Richter 可是微软技术教育的老前辈了，他在课上就说：别去捕获你不知道该怎么处理的 exception，由它去吧。

我一愣，问道：不去捕获 exception，那我们的程序就崩了呀。

Jeff 说：让他崩，因为 crash is awesome!!!

我呆了，勉强同意他的观点，倒不是因为我被说服了，只是因为他是一个老同志老前辈。

几个月后，我处理了一个线上 bug，狠狠被刺痛了一回，彻底改变了我的观点。

那一整子，正好我轮上 on-call，产品环境总是爆出的一个问题， .net 服务进程跑着跑着就死了，可是又搞不清楚什么原因，每次只能重启服务器，然后去分析 dump 文件，分析又分析不出什么所以然来，就这么折腾了一个星期，是不是就有 on-call 电话打过来要处理，真是苦不堪言。

最后，是一个晚上我突然灵光一下，心想……（此处省略 10000 字），我当时怎么分析出来的不重要，重要的是最后我发现问题的根源，是因为前人写的 code 太锉了，很多 exception 被抛出来之后，都被 catch 住，然后打了一个 log，然后继续运行，这就是邪恶的根源。

本来，当发生这些 exception 的时候，可以直接 crash 的，这样工程师只要检查 crash 时间之前的 log，就能够很容易发现问题；可是，前人写得代码却生吞了这些 exception，然后装作没事人一样继续运行，程序的状态已经不正常了，却依然在苟且运行，这样的不正常状态越积越多，终有撑不住死掉的时候，但是，那已经是几周之后了，工程师怎么可能会把表现的问题和几周前的 log 关联起来！

所以说，吞掉 exception，不让该 crash 的情况 crash，害人害己，我深深咒骂这么写 code 的前人。

很多初级选手选择吞掉 exception 坚持不 crash，是为了让服务“持续稳定运行”，为了让服务“具有高可用性”，错！错得厉害！要让服务稳定而高可用，靠的可不是一台服务器，应该用多服务的方式来应对，即使在产品环境下，出了不能处理的 exception，就应该由它去，不该你处理的异常就别去处理，让调用栈上流的去处理，如果调用栈上层也没有人处理，那就崩溃吧，暴露问题总比隐藏问题要好。

回想 Jeff Richter 所说的：当 exception 发生的时候，表示不可预料的事情发生了，每个函数只应该处理它能够处理的 exception，如果不能处理，就放它过去，交由上面的（人）去处理，处理不了就让它崩溃。

Let it Crash!