内容简介：该崩溃的时候就崩溃吧，至少写程序应该是这样
“就让它崩溃”（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!
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Python Cookbook 中文版，第 3 版
David M. Beazley、Brian K. Jones / 陈舸 / 人民邮电出版社 / 2015-5-1 / 108.00元
《Python Cookbook（第3版）中文版》介绍了Python应用在各个领域中的一些使用技巧和方法，其主题涵盖了数据结构和算法，字符串和文本，数字、日期和时间，迭代器和生成器，文件和I/O，数据编码与处理，函数，类与对象，元编程，模块和包，网络和Web编程，并发，实用脚本和系统管理，测试、调试以及异常，C语言扩展等。 本书覆盖了Python应用中的很多常见问题，并提出了通用的解决方案。......一起来看看 《Python Cookbook 中文版，第 3 版》 这本书的介绍吧!
