描述
开 本: 16开纸 张: 胶版纸包 装: 平装是否套装: 否国际标准书号ISBN: 9787302394495
作者以诙谐幽默的文笔，于谈笑间揭示异常处理的来龙去脉，兼顾实用性和趣味性，非常适合善于思考和勤于实践的软件工程师阅读，也适合软件学院和计算机相关专业学生参考。
目录/Contents
Part 1 异常处理的现状
Chapter 01 你对异常处理的了解有多少？ 3
02 异常处理的重要性 6
03 “种花”电信，我真是猜不透你啊！ 14
04 HTC One X—— 发现一个Bug
21
05 HTC One X—— 我只是想打通电话呀！ 25
06 HTC One X—— 拍照的错误消息描述 30
07 可靠性可以是一门生意 35
Column A． 倒霉的人很适合当神秘客 39
Part 2 异常处理的基本观念
Chapter 08 强健性大战曲—— 魅影危机 47
Column B． 找不到数据，要传回Null还是丢出异常？ 54
09 异常处理的四种脉络 57
10 面向对象语言的异常处理机制 69
11 你的汽车有多耐撞？谈谈异常安全性 86
12 对比异常处理和容错设计 90
Column C． 网络又断了 95
Part 3 JAVA语言的异常处理机制
Chapter 13 Java的异常处理 101
14 我的异常被finally块覆盖了 110
15 被打压的异常—— 抢救异常大作战 116
16 清理失效的语义要表达清楚 122
17 自己制作“被打压的异常” 131
18
Try、Catch和Finally的责任分担 144
Column D． 这是你的问题，不是我的问题 152
Chapter 19 异常处理失败，怎么办？ 156
20 已查异常与未查异常的语义与问题 159
21 接口演进 164
Part 4 为什么异常处理那么难？异常处理的4+1观点
Chapter 22 用途观点 173
23 设计观点 177
24 处理观点 181
25 工具支持观点 185
26 流程观点 191
Column E． 你如何评价成功 198
Part 5 强健度等级与异常处理策略
Chapter 27 异常处理设计的步—— 决定强健度等级 203
28 强健度等级1—— 错误报告的实现策略 211
29 强健度等级2—— 状态恢复的实现策略 216
30 强健度等级3—— 行为恢复的实现策略 223
Column F． VMWare越狱之替代方案 231
Chapter 31 异常类的设计与使用技巧 235
32 终止或继续 245
33 自动化更新 249
Column G． 升级、降级，傻傻分不清楚 253
Part 6 异常处理坏味道与重构
Chapter 34 异常处理坏味道 261
Column H． 仙人打鼓有时错—— 谈谈Clean Code一书中介绍的异常处理 269
Chapter 35 用异常代替错误码 275
36 以未查异常取代忽略已查异常 281
37 以重新丢出异常代替空的处理程序 285
38 使用外层Try语句避免意外终止 290
39 以函数取代嵌套的Try语句 295
40 引入Checkpoint类 301
41 引入多才多艺的Try块 309
Column I． 客户满意，老板赚钱，你护肝 317
Chapter 42 一个函数只能有一个Try语句 326
Column J． 眼力测试 332
Appendix A．眼力测试参考答案 340
参考文献 349
序言/Preface
这是一本异常处理的书，
也是一本软件设计的书。
是的，身为一位专业的软件开发人员，从小到大你可能学过各式各样的软件设计技术与方法。从基础的程序语言（C、C++、Java、C#、VB.NET、Objective-C、JavaScript、Ruby、Python等）、数据结构与算法，到面向对象分析与设计、设计模式、软件架构以及各种敏捷开发实践，包含自动化测试、测试驱动开发、行为驱动开发、持续集成和敏捷设计原则等。以上，所有的“大师”费尽心力，都在告诉你“如何设计软件的光明面？”
什么？！软件的光明面？是的，软件跟宇宙万物一样，有光明面也有黑暗面。软件的光明面就是“正常行为”（normal
behavior），而黑暗面则是“异常行为”（abnormal behavior）。就好像一般民众看到“黑道”与“坏人”，人人莫不避而远之。大部分的开发人员对于软件的“黑暗面”与“异常行为”，都感到很头大，在内心中抱持着“闭上眼睛就以为看不见”的心态：“反正程序看起来可以动就好了”，您说是吗？
软件设计包含着正常行为与异常行为，两者相互影响，忽略任何一方，都可能让原本精心规划的设计变得不堪一击。既然异常行为的设计那么重要，与正常行为相较，为什么很少人谈论异常行为？
因为很难。
对付异常行为很难，因为它“躲在正常行为的影子下”，很容易被有意、无意地忽略。其次，它与正常行为“水乳交融”、“我中有你，你中有我”。套一句软件开发的术语，它是一种“横切关注点”（cross-cutting concern），需要具备怪医黑杰克与庖丁解牛的能力，同时关注方方面面，才有可能让你在对“病人”（程序）进行“外科手术”（处理异常）的时候，避免不小心切断动脉，导致“失血过多”（越改越乱）而让病人提早上天堂的窘境。
俗话说“夜路走多了，自然会碰到鬼”，本书累积了Teddy“碰到鬼”的经验，从异常处理设计出发，专门探讨软件设计黑暗面的问题，希望补足开发人员长久以来所欠缺的“维他命”。
这是一本写给开发人员的书，
也是一本写给管理阶层的书。
看到书名，你可能会以为这是一本写给开发人员的书。错！开发人员的钱要赚，管理阶层的钱也要赚。嗯嗯，Teddy的意思是说，异常处理做得好，可以提升软件的强健度，提高客户满意度，帮公司赚大钱，减少程序错误，早点下班回家陪家人，并顺便护肝。
本书分为6部分42章，有些地方技术含量相对较低，对于不想知道太多异常处理实现细节的管理阶层，可以只看这几个部分。
另外像是Column A“倒霉的人很适合当神秘客”、Column
C“网络又断”、Column D“这是你的问题，不是我的问题”、Column E“你如何评价成功”、Column G“升级、降级，傻傻分不清楚”、Column I“客户满意，老板赚钱，你护肝”，也很适合管理阶层当作小说来看。
至于开发人员，当然是要“怒看”整本书的内容才够“给力”。
是否与程序语言相关
异常处理设计重点不在程序语言和语法，而在背后的设计原理。虽然本书范例以Java语言为主，但也一并讨论了许多Java语言和C#语言（支持与不支持checked
exception的双方代表）在异常处理设计精神与作法上的差异。书中所介绍的异常处理设计观念、名词、原则、方法与重构，只要是面向对象语言，不管是Java、C#、VB.NET、Python、Ruby等，差不多都适用。
至于采用Java语言作为例子的原因很简单：因为它是当代流行的商业语言里面，异常处理机制困难（或是说“讨厌”）的语言。搞懂了Java的异常处理，再应用到其它面向对象语言，就好像喝开水一样，变得非常容易。
以上用白话文来说就是，不管你使用什么语言，都应该买一本带回家。
书中用语和排版
以一本中文书而言，书中的英文稍微多了一些。有些英文术语译成中文之后，阅读起来总是少了点味道，所以Teddy会选择性地保留一些英文，例如checked exception和unchecked exception。但英文名词次出现的时候，在它的“前后”或“附近”一定会有相对应的中文翻译或说明。
为了区分特别的名词，本书程序代码采用Courier New字体，而书中提到模式名称（pattern name）、坏味道（bad smell）、重构（refactoring），则使用大写开头的英文斜体字表示。例如Command、Dummy Handler。对于本书中所提出的异常处理重构，除了以斜体字表示以外，还会在名称之后加上《重构》一书中介绍该重构的章节页码，例如Replace Error Code with Exception（299）。
一些软件领域常用的英文名词书中直接用中文表示，例如用function与method翻译成“函数”（有些中文书会使用“函数”或“方法”）。class、object、instance和type用“类”、“对象”、“实例”和“类型”表示。thread、process用“线程”和“进程”称呼。Application Programming Interface（应用程序编程接口）则直接使用API。
后，重要的概念和知识点以黑体字加以强调。
***
本书许多内容初来自于Teddy的博士论文“Java异常处理：模型、重构与模式”（原题目为Java Exception Handling: Models, Refactorings, and Patterns）以及工作上的实践经验，经改写后，从2007年起陆续发表在“搞笑谈软工”博客，后集结成册再加上“强烈月光照射”之后，变身成为大家现在看到的这本书。书中内容经过Teddy多次修改与审校，但刻意保留原本在博客中以“乡民”称呼读者的方式。此为特意为之，并非Teddy偷懒，特此说明。
乡民们若对本书内容有任何问题、心得、称赞，或者发现错误，或是看到不爽想翻桌的时候，欢迎直接写信到[email protected]给Teddy或加入Facebook上的“搞笑谈软工社团”，网址为https://www. facebook.com/groups/teddy.tw/，我们一起讨论。
1 异常处理的现状
Chapter | 01.
你对异常处理的了解有多少？
本
书首先帮乡民们做一次简单的YES or NO的测验。以下有20题是非题，回答YES的数目越多，代表乡民们对于异常处理的了解越深入。请凭直觉回答以下问题，请准备好一支笔，计时10分钟，开始作答。
Q1 你曾经读过任何一本专门讨论异常处理的书籍吗？
___________________________________________________
Q2 你是否了解不良的异常处理，轻则造成用户不便，重则造成生命财产的损失？
___________________________________________________
Q3 你知道“缺陷”（fault）、“错误”（error）、“失效”（failure）、“异常”（exception）的差别吗？
___________________________________________________
Q4 你知道区分“设计缺陷”（design fault）和“组件缺陷”（component fault）对于异常处理有何帮助吗？
___________________________________________________
Q5 你听过面向对象语言异常处理机制的十大设计因素吗？
___________________________________________________
Q6 你能说出Ruby和Java/C#的异常处理机制的差别吗？
___________________________________________________
Q7 你知道异常处理设计的决策有哪些脉络（context）可以参考吗？
___________________________________________________
Q8 你能够区分“异常处理”和“容错设计”的差别吗？
___________________________________________________
Q9 你清楚NullPointerException或NullReferenceException的处理方法吗？
___________________________________________________
Q10 你知道try-catch-nally各自负担何种责任吗？
___________________________________________________
Q11 你能说出Java的“checked exception”（已查异常）与“unchecked exception”（未查异常）有何不同吗？
___________________________________________________
Q12 你知道哪些Java异常类套用Exception
Hierarchy设计模式，哪些又套用Smart Exception设计模式吗？
___________________________________________________
Q13 你知道在敏捷方法中如何让异常处理设计逐步成长吗？
___________________________________________________
Q14 你能够判断一个程序是否存在“异常处理坏味道”（exception handling bad smell）吗？
___________________________________________________
Q15 你会写“重试”（retry）的异常处理程序吗？
___________________________________________________
Q16 你知道一个函数如果只有一个try语句有什么好处吗？
___________________________________________________
Q17 你知道C#和Objective-C的异常类为什么要实现Variable State设计模式吗？
___________________________________________________
Q18 你知道在数据库里面找不到数据要传回null还是丢出异常吗？
___________________________________________________
Q19 你知道异常处理程序执行失败该怎么办吗？
___________________________________________________
Q20 你知道花小钱却可大幅提升软件强健度的方法吗？
___________________________________________________
***
友藏内心独白：看完本书之后，就可以做到全部回答YES。
Chapter | 02.
异常处理的重要性
智能手机的启示
2007年3月，Teddy买了一支具有GPS导航功能的智能手机Mio A701(见图2-1)。在新鲜感还没有消失之前，Teddy在网络上到处寻找关于智能手机的数据，有人提到执行Windows Mobile操作系统的智能手机，过一阵子就要帮它“还魂”（重新启动）。不知道是应用软件没写好，还是操作系统不稳定，相较于个人电脑，这些智能手机更容易当机，需要经常性的重新开机。既然大家都有重新开机的“需求”，很多机种干脆做了一个重置机（reset）按钮，并将其设计在机体的下方。为了避免用户不小心按到重置按钮，所以重置按钮都会设计成凹进去的，需要用触控笔尖尖的那一端来碰触重置按钮，看起来就好像在帮手机“还魂”一样
。
图2-1：Mio A701 的重置按钮（照片右方印有 RESET 字样）
Teddy用了智能手机没多久之后，便强烈感受到“还魂”这个“功能”实在太重要了。为什么智能手机这么容易当机？一切就好像时空倒转，回到当年那Windows 3.0/3.1动不动就出现蓝底白字的时代，需要不断地按下计算机上面的重置按钮。
软件出问题导致计算机或是电子设备当机的原因很多，其中一个常见原因就是不良的异常处理。一个软件系统的行为，可以区分为正常行为（normal behavior）与异常行为（abnormal或exceptional behavior）这两大类。在产品开发过程中，由于项目日程紧迫、人力有限、经验不足等因素，开发人员能够在上市之前，把产品在正常状况之下所应具备的功能做出来，就已经要偷笑了，哪里还有闲功夫考虑异常状况。因此，虽然妥善处理程序中所发生的异常，可以增强软件的强健度（robustness），也就是让软件比较不容易当机。但碍于现实状况，很多软件的“异常处理”能力都处于严重不足的情况。
乡民甲：异常处理是什么？可以吃吗？
耶……你该思考的是，遇到异常时该怎么办？乡民们可能会想：“嘿嘿嘿，很简单的啦，只要把异常捕获（catch）起来然后直接忽略不就好了！虽然有点像有窝藏犯人的嫌疑，反正眼不见为净，写程序的是我，我不讲老板也不会知道的啦。”甚至有些开发人员对于程序执行可能会遭遇异常状况这件事“浑然不知”，抱持着“反正程序当掉客户自然会出声，到时候再来解决bug就好了，搞不好还可以因此争取到一些打混摸鱼的时间。”稍微负责一点的开发人员可能会捕获异常并将其写到日志文件、直接打印出来或是交给程序外围来处理（通常是启动该程序的函数，例如main函数或是某个线程）。至于那种会思考具体异常处理策略的开发人员，算是“人间”，可遇而不可求啊。
好吧，就算乡民从现在开始立志要成为这种“人间”，打算大展身手好好修理一下这些“窝藏”在程序中不请自来且会造成系统不稳定的不速之客，但是，要怎么做？这时候，你静下心来用力回想一下，距今N年前的学生时代，是否有什么课程曾经教过异常处理设计？嗯……好像没有。没关系，身为一位有理想、有抱负的开发人员，包里随时藏着几本程序语言的书也是很正常的事情。先翻翻VB这一本，再看看Java这一本，还有C++、C#、ObjectiveC、Ruby、Python、JavaScript等。奇怪，怎么好像除了把异常这个“烫手山芋”往外丢（rethrow）或是直接输出到屏幕上，难道就没什么其它更好的处理方法了吗？此时，你在内心吶喊着：“的天神，请赐予我神奇的力量，让我好好地处理掉这些该死的异常吧！”
重新开机不就好了？！
有些乡民可能会想：“有那么严重吗？”系统不稳定，重新启动一下就好了啊。现在让Teddy在“公堂之上假设一下”，看看系统不稳会造成什么问题。
系统不稳导致重新启动，会导致以下后果。
l 工作无法继续：假设你正在用计算机转换多媒体文件或是执行复杂的科学模拟运算，工作执行到一半软件当机。重新启动之后所有工作从头开始，之前花费的时间全部浪费。此外，工作无法持续也会进一步导致不良的用户体验（见图2-2）。
图2-2：系统不稳定所造成的表面影响
l 用户体验不佳：想象你正在用手机跟重要客户通电话，电话讲到一半手机突然重新启动。或是在一个陌生城市里使用导航软件，开车过程中导航软件突然当机。以上状况，轻则损失金钱，重则造成生命危险。
如图2-3所示，工作无法继续与用户体验不佳，进一步导致用户对产品不满，不断地通过各种渠道抱怨。公司收到如雪片般飞来的客户投诉，便催促开发人员赶紧处理。开发人员在压力之下忙于到处救火，在仓促修改之下，系统稳定性时好时坏。有时修复了一个bug，还会产生其他更多bug，导致恶性循环，每天加班到“爆肝，永世不得超生”，一直到离职或是公司倒闭为止。
图2-3：系统不稳定所形成的负向封闭循环造成系统更加不稳定
如图2-4所示，人的忍耐是有限度的，用户经过一番抱怨与等待之后，产品稳定性不见提升，因此对产品失去信心。
如图2-5所示，客户对产品不满意，以后还会购买贵公司的任何产品吗？同时，过多的产品客户投诉及抱怨，也会导致口碑不佳，伤害公司形象与商誉。这两者所造成的伤害，都会影响公司获利。这就是系统不稳定对公司所造成的问题，绝非要求用户重新启动或是反过头来怒喝用户：“自由世界，你喜欢退你就退”，于是乎二一推作五，干脆推个一干二净，当作没事情发生。
图2-4：客户对产品不满意
图2-5：系统不稳定终将影响公司获利
为什么系统会不稳定？
认识到系统不稳定所造成的问题之后，接下来要思考是什么原因造成系统不稳定？依据Meyer 的看法，原因只有两点：就是“正确性不足”与“强健度不足”（见图2-6）。
图2-6：系统不稳定的两个根源
如图2-7所示，正确性（correctness）和强健度（robustness，也称“健壮度”或“健壮性”）是两个不同但彼此互补的概念。如果一个函数是依据规格来实现的，我们便会说这个函数是正确的。例如，一个计算两个整数相加的函数add，传入1和2，计算之后传回3。依据加法规格，这个结果是正确的。如果1+2传回5，这个函数就是不正确的。正确性是建构一个稳定系统的基本条件，不正确的函数，就算是在正常的状况之下，也无法表现出稳定的系统行为。
图2-7：正确性与强健度的关系
强健度是指系统对于异常的响应能力。例如，一个储存数据的save函数，规格书只规定接受一个文件名与一个字符串，然后将这个字符串存入指定的文件，并覆盖原始文档中的内容。考虑到异常情况，如果发生储存空间不足、系统忙碌、无法存取储存媒体、储存到一半停电等状况，在规格书中并没有特别描述。如果save函数在这些异常状况之下，依然可以让系统处在一个正常的状态，则此save函数就具有较高的强健度。一个人如果身强体壮，当未知的流感病毒入侵时，就比较不容易感冒生病。同样，软件如果身强体壮，也就不容易因为异常情况而轻易当机。
***
长期以来，不论是在学校或是在业界，关于软件开发的技术培训，绝大部分焦点都着重于“正确性”上面。举凡程序语言、数据结构、算法，面向对象分析与设计、设计模式、测试、软件重构等，这方面的资料已经很多，Teddy在这里就不再锦上添花。
然而，关于如何通过异常处理来增强软件系统的“强健度”，相关数据并不多，就算有也是零零散散的片言只语或是过于理论的研究论文，不容易直接应用于工作之上。因此，本书抱持着“雪中送炭”的精神，耕耘这一块“不正常的软件行为领域”。期望让开发人员可以在轻松又不失严肃的情境之下，了解异常处理设计的知识，做出更好、更稳定的软件，让公司赚大钱，自己也顺带升官发财。
以上，就是值得购买本书回家珍藏的原因。
***
友藏内心独白：花小钱，赚大钱，可能吗？继续看下去就知道
评论
还没有评论。