软件构造-犯错的艺术——健壮性与正确性，异常，防御式编程，debugging与test的思考与总结

Posted 2022-02-05 giere

 

健壮性与正确性

健壮性与正确性是不同的——一个倾向于使程序尽可能保持运行，即使遇到错误，一个倾向于使程序尽可能正确，不在意保持运行

异常

异常分为两种——checked exception与unchecked exception

二者的区别在于：

• checked exception需要显式的处理，说白了就是编程者必须要么用catch抓住它，然后在try中想办法处理掉，要么显式的将这个异常扔到调用的上一级方法，也就是甩锅。总而言之，你永远不能无视checked exception
• unchecked exception则完全相反，你不捕捉不到它们。因为这些异常一旦产生，就像接到了烫手山芋一样，容不得我们再把他保留著或者throw到上一级方法，这些异常会在其产生的地方直接中止程序，并在控制台打印错误信息。

 

 

 异常使用的注意事项

• catch 不能独立于 try 存在。
• 在 try/catch 后面添加 finally 块并非强制性要求的。
• try 代码后不能既没 catch 块也没 finally 块。
• try, catch, finally 块之间不能添加任何代码。

关于异常的LSP原则

• 如果子类型中override了父类型中的函数，那么子类型中方法抛出的异常不能比父类型抛出的异常类型更广泛
• 子类型方法可以抛出更具体的异常，也可以不抛出任何异常
• 如果父类型的方法未抛出异常，那么子类型的方法也不能抛出异常。

那么结合我之前对继承关系的理解，——前置条件不能加强，后置条件不能减弱

如果父类抛出了一个异常，子类抛出一个更具体的异常——？

这我能理解。因为异常也可以看做方法的后置条件，后置条件不能减弱，固异常变得更加具体是完全符合的

如果父类抛出了一个异常，子类可以不抛出异常————？？？

那么这个就只能够理解为”不抛出任何异常是比抛出某一种异常更加具体的条件。”， 我们可以就这样理解，不跑出异常相当于把异常抛出的条件无限加强。

 

 防御式编程

防御式编程(Avoiding debugging)，顾名思义，就是为了减少bug的出现而采用的一系列措施。

第一道防线：不让bug产生

听起来很厉害哈哈哈哈，说得倒轻巧。

其实这第一道防线的意思就是减少bug的一些编程技巧，比如说：

• 静态检查
• 动态检查
• 使用immutable的对象
• 使用immutable的引用

第二道防线：缩小bug的影响范围

也就是老生常谈的fail fast

使用Assertion是一个重要技巧，但是哪些东西需要使用asserrtion呢，这也有一些套路的

• 需要assert的
  • 方法参数的条件（前置条件）
  • 方法的返回值的条件（后置条件）
• 　　不需要assert的
  • java中的算式等从语法角度不会犯错的（也就是不要试图用assert寻找虚拟机的错误）
  • 外部的错误（比如说用户的输入，文件的存在性等，这个我们管不着）

其它方法

• Incremental Development
• Modularity
• Encapsulation

Debugging

 。。。。。。（这里真的没有什么内容啊）

Testing

测试用例很重要，但是也很繁琐。本学期软件构造课的实验中，对我来说的最大的噩梦就是为自己的代码写test用例了。

如何选择测试用例

简而言之，就是通过对方法的输入空间和解空间，根据方法的特性来设定测试用例。

一个简单的例子：

如果要测试BigInteger.multiply(BigInteger b)

 

如何划分？

• 正值，负值与0
• 很小的值，很大的值
• 特殊值（比如0，-1，1）

然后只要按照这些划分来写测试用例即可。

这是一个很浅显的例子，事实上ppt与mit的reading中都明确给出了关于等价类划分的一套证明，但我认为如果要理解测试用例的书写，只需要理解

• 错误经常发生在边界条件处
• 对每一种情况选择一个代表元素

即可。

Documenting test strategy

选择测试用例的划分是编程时经常用到的技巧，但是对于考试题来说，还必须会将测试用例书写下来才行。不要到考场上才慌慌张张想着怎么排版按什么格式

 

 白盒测试与黑盒测试

黑盒测试就是在不知道方法的内部实现的情况下，只根据前置条件和后置条件对方法进行测试，这是最常用的。

而白盒测试则是对方法的内部实现进行测试 例子？