第四章是关于异常的。
建民欧巴上课的时候举过例子，如果如果两个进程需求冲突，进程1在等进车行哥2返回的数据，进程2在等进程1返回的数据，那程序就锁死了。
这个时候就要配平资源。只要在编程，我们就要管理资源：内存，事务，线程，文件，定时器——所有数量有限的事物，大多数时候，资源使用遵循一种可预测的模式：你分配资源，使用它，然后解决其分配。但是，对于资源分配的处理，许多开发者没有始终如一的计划，所以让我们提出一个简单的：要有始有终。意味着，分配某项自愿的例程或对象因该负责解除该资源的分配。
调试是一个敏感话题。我们讨厌被人说程序有bug，我们也讨厌别的程序有bug。
发现别人bug以后，要去修正问题，而不是发出指责。
调试代码的时候要关闭自我防护措施，记住第一准则“不要恐慌”
同样我们也要防止近视，打破自己的界限。边界测试+模拟用户测试能更好的解决问题。
bug的出现可能是在os中，在第三方的软件里，但是更多的情况是在自己写的代码中，遇到问题不要假定自己的代码没问题，要去证明自己的代码没问题
- 橡皮鸭哲理：
找到问题的原因简单有效的方法是：向别人解释它。解释这段代码是要做什么，他就像澡盆里面上下晃动的橡皮鸭，只顾点头，一直这样下去，问题就会从屏幕里跳出来。（工作中我们可能不会向别人解 释，那就自己向自己解释。)
附上第三章第四章的tips：
20.用纯文本保存知识 Keep Knowledge in Plain Text
纯文本不会过时。它能够帮助你有效利用你的工作。并简化掉时和测试。
21.利用命令shell的力量 Use the Power of Command Shells
当图形用户界面无能为力时使用shell。
22.用好一种编辑器 Use a Single Editor Well
编辑器应该是你的手的延伸；确保你的编辑器是可配置、科扩展和可编程的。
23.总是使用源码控制 Always Use Source Code Control
源码控制是你的工作的时间机器–你能够回到过去。
24.要修正问题，而不是发出指责 Fix the Problem, Not the Blame
bug是你的过错还是别人的过错，并不是真的很有关系–它仍然是你的问题，它仍然需要修正。
25.调试时不要恐慌 Don’t Panic When Debuging
做一次深呼吸，思考什么可能是bug的原因。
26.“Select”没有问题 “Select” Isn’t Broken
在OS或编译器、甚或是第三方产品或库中很少发现bug。bug很可能在应用中。
27.不要假定，要证明 Don’t Assume It - Prove It
在实际环境中–使用真正的数据和辩解条件–证明你的假定。
28.学习一种文本操纵语言 Learn a Text Manipulation Language
你用每天的很大一部分时间处理文本，为什么不让计算机替你完成部分工作呢？
29.编写能编写代码的代码 Write Code That Writes Code
代码生成器能提高你的生产率，并有助于避免重复。
30.你不可能写出完美的软件 You Can’t Write Perfect Software
软件不可能完美。保护你的代码和用户，使它（他）们免于能够预见的错误。
31.通过合约进行设计 Design with Contracts
使用合约建立文档，并检验代码所做的事情正好是它声明要做的。
32.早崩溃 Crash Early
死程序造成的危害通常比有问题的程序要小得多。
33.用断言避免不可能发生的事情 Use Assertions to Prevent the Impossible
断言验证你的各种假定。在一个不确定的世界里，用断言保护你的代码。
34.将异常用于异常的问题 Use Exceptinos for Exceptional Problems
异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物。
35.要有始有终 Finish What You Start
只要可能，分配某资源的例程或对象也应该负责解除其分配。