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

 

健壮性与正确性

健壮性与正确性是不一样的——一个倾向于使程序尽量保持运行，即便遇到错误，一个倾向于使程序尽量正确，不在乎保持运行

异常

异常分为两种——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

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

 

 白盒测试与黑盒测试

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

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