要点
- 最终产品代码中对错误的处理方式要比“垃圾进，垃圾出”复杂的多。
- 防御式编程技术可以让错误更容易发现、更容易修改，并减少错误对产品代码的破坏。
- 断言可以帮助人尽早发现错误，尤其是在大型系统和高可靠性的系统中，以及快速变化的代码中。
- 关于如何处理错误输入的决策是一项关键的错误处理决策，也是一项关键的高层设计决策。
- 异常提供了一种与代码正常流程角度不同错误处理手段。如果留心使用异常，它可以称为程序员们知识工具箱中的一项有益补充，同时也应该在异常和其他错误处理手段之间进行权衡比较。
- 针对产品代码的限制并不适用于开发中的软件。你可以利用这一优势在开发中添加有助于更快地排查错误的代码。
核对表 （防御式编程）
一般事宜
- 子程序是否保护自己免遭有害输入数据的破坏？
- 你用断言来说明编程假定吗？其中包括了前条件和后条件吗？
- 断言是否只是用来说明从不应该发生的情况？
- 你是否在架构或高层设计中规定了一组特定的错误处理技术？
- 你是否在架构或高层设计中规定了是让错误处理更倾向于健壮性还是正确性？
- 你是否建立了隔栏来遏制错误可能造成的破坏？是否减少了其他需要关注错误处理的代码的数量？
- 代码中用到的辅助调试的代码了吗？
- 如果需要启用或禁用添加的辅助助手的话，是否无须大动干戈？
- 在防御式编程时引入的代码量是否适宜——既不过多，也不过少？
- 你在开发阶段是否采用了进攻式编程来使错误难以被忽视？
异常
- 你在项目中定义了一套标准化的异常处理方案吗？
- 是否考虑过异常之外的其他替代方案？
- 如果可能的话，是否在局部处理了错误而不是把它当成一个异常抛到外部？
- 代码中是否避免了在构造函数和析构函数中抛出异常？
- 所有的异常是否都与抛出它们的子程序处于同一个抽象层次上？
- 每个异常是否都包含了关于异常发生的所有背景信息？
- 代码中是否没有使用空的catch语句？（或者如果使用空的catch语句确实很合适，那么明确说明了吗？）
安全事宜
- 检查有害输入数据的代码是否也检查了故意的缓冲区溢出，SQL注入、HTML注入、整数溢出以及其他恶意输入数据？
- 是否检查了所有的错误返回码？
- 是否捕获了所有异常？
- 出错消息中是否避免出现有助于攻击者攻入系统所需的信息
安全、断言、异常