主要思想：
子程序应该不因传入错误数据而被破坏， 哪怕是由其他子程序产生的错误数据；换一种说法是， 程序员应该承认程序都是有问题的都需要被修改。
保护程序免遭非法输入数据破坏
软件开发领域“垃圾进，垃圾出”的原则已经过时，应该做到： 垃圾进，什么都不出；垃圾进，出错误提示；不许垃圾进。做法如下：
- 检查所有来源于外部的值
- 检查子程序所有输入参数的值
- 决定如何处理错误的输入数据
Assertions 断言
在程序开发和使用期间，用于程序自检的代码即为断言； 使用断言可以在程序出现问题时让程序员更快速的根据断言给出的信息排查问题和原因。
断言通常含有两个参数：一个描述假设为真时的情况的布尔表达式，一个断言为假时需要显示的信息。建立自己的断言机制
使用断言的指导建议
- 用错误处理代码来处理预期会发生的情况， 用断言来绝不应该发生的状况
- 避免把需要执行的代码放到断言中
- 用断言来注解并验证前后条件
- 对于高健壮性的代码， 应该线使用断言再处理错误
错误处理技术
可以使用的技术：返回中立值；换用下一个正确数据（如读取数据）；返回与前次相同的数据（如图像显示处理）；换用最接近的合法值（超过预设范围的值）；把警告信息记录到日志文件中；返回一个错误码；调用错误处理子程序或对象；当错误发生时显示出错信息；用最妥当的方式在局部处理错误；关闭程序。
健壮性与正确性
二者在某种意义上是相斥的
高层次设计对错误处理方式的影响
异常 Exceptions
把代码中的错误和异常事件传递给调用方代码的一种特殊手段。
审慎明智的使用异常：
- 用异常通知程序的其他部分，发生了不可忽略的错误
- 只在真正例外的情况下才抛出异常
- 不能用异常来推卸责任
- 避免在构造函数和析构函数中抛出异常， 除非你在同一个地方把他们捕获
- 在恰当的抽象层次抛出异常（如抛出更底层异常）
- 在异常消息中加入导致异常发生的全部信息
- 避免使用空的catch语句
- 了解所有函数库可能抛出的异常
- 考虑创建一个集中地异常报告机制
- 把项目中对异常的使用标准化
- 考虑异常的替换方案
隔离程序，使之包容由错误造成的伤害
隔栏，一种代码的容损策略，如常用的： 在输入数据时将其转化为恰当的类型。
辅助调试的代码
不要自动地把产品版的限制强加于开发版 之上
尽早引入辅助调试的代码 rails中的 pry、 debugger等
采用进攻式编程
在开发阶段让异常尽量显现出来，而在产品真正运行时能够自我修复
计划移除调试辅助的代码
- 使用版本控制工具
- 使用内置的预处理器
- 编写你自己的预处理器
- 使用调试存根
确定在产品代码中该保留多少防御式代码
- 保留那些检查重要错误的代码
- 去掉检查细微错误的代码
- 去掉可以导致程序硬性崩溃的代码
- 保留可以让程序稳妥崩溃的代码
- 为你的技术支持人员记录错误信息
- 确认留在代码中的错误信息是友好的
对防御式变成采取防御式姿态
用防御的姿态适当的因地制宜的使用防御式代码
网友评论