# 核对表：防御式编程 ## 一般事宜 - [] 子程序是否保护自己免遭有害输入数据的破坏？ - [] 你用断言来说明编程假定吗？其中包括了前条件和后条件吗？ - [] 断言是否只是用来说明从不应该发生的情况？ - [] 你是否在架构或高层设计中规定了一组特定的错误处理技术？ - [] 你是否在架构或高层设计中规定了是让错误处理更倾向于健壮性还是正确性？ - [] 你是否建立了隔栏来遏制错误可能造成的破坏？是否减少了其他需要关注错误处理的代码的数量？ - [] 代码中用到辅助调试的代码了吗？ - [] 如果需要启用或禁用添加的辅助助手的话，是否无须大动干戈？ - [] 在防御式编程时引入的代码量是否适宜——既不过多，也不过少？ - [] 你在开发阶段是否采用了进攻式编辑来使错误难以被忽视？ ## 异常 - [] 你在项目中定义了一套标准化的异常处理方案吗？ - [] 是否考虑过异常之外的其他替代方案？ - [] 如果可能的话，是否在局部处理了错误而不是把它当成一个异常抛到外部？ - [] 代码中是否遮免了在构造函数和析构函数中抛出异常？ - [] 所有的异常是否都与抛出它们的子程序处于同一抽象层次上？ - [] 每个异常是否都包含了关于异常发生的所有背景信息？ - [] 代码中是否没有使用空的catch语句？（或者如果使用空的catch语句确实很合适，那么明确说明了吗？ ## 安全事宜 - [] 检查有害输入数据的代码是否也检查了故意的缓冲区溢出、SQL注入、HTML注入、整数溢出以及其他恶意输入数据？ - [] 是否检查了所有的错误返回码？ - [] 是否捕获了所有的异常？ - [] 出错消息中是否避免出现有助于攻击者攻入系统所需的信息？