内容简介：该崩溃的时候就崩溃吧，至少写程序应该是这样
“就让它崩溃”（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!
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
计算机组成（第 6 版）
Andrew S. Tanenbaum、Todd Austin / 刘卫东、宋佳兴 / 机械工业出版社 / 2014-8-19 / CNY 99.00
本书采用结构化方法来介绍计算机系统，书的内容完全建立在“计算机是由层次结构组成的，每层完成规定的功能”这一概念之上。作者对本版进行了彻底的更新，以反映当今最重要的计算机技术以及计算机组成和体系结构方面的最新进展。书中详细讨论了数字逻辑层、微体系结构层、指令系统层、操作系统层和汇编语言层，并涵盖了并行体系结构的内容，而且每一章结尾都配有丰富的习题。本书适合作为计算机专业本科生计算机组成与结构课程的教......一起来看看 《计算机组成（第 6 版）》 这本书的介绍吧!
