内容简介:该崩溃的时候就崩溃吧,至少写程序应该是这样
“就让它崩溃”(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!
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Windows黑客编程技术详解
甘迪文 / 人民邮电出版社 / 2018-12 / 108
《Windows黑客编程技术详解》介绍的是黑客编程的基础技术,涉及用户层下的Windows编程和内核层下的Rootkit编程。本书分为用户篇和内核篇两部分,用户篇包括11章,配套49个示例程序源码;内核篇包括7章,配套28个示例程序源码。本书介绍的每个技术都有详细的实现原理,以及对应的示例代码(配套代码均支持32位和64位Windows 7、Windows 8.1及Windows 10系统),旨在......一起来看看 《Windows黑客编程技术详解》 这本书的介绍吧!