软件构造博客（7）-Robustness and Correctness

本文主要是介绍软件构造博客（7）-Robustness and Correctness，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

进入软件构造最关键的质量特性——健壮性和正确性。
使用错误处理和exception提高robustness
使用断言、防御式编程提高correctness

含义

健壮性：系统在不正常输入或不正常外部环境下仍能够表现正常的程度
面向健壮性的编程:
1.处理未期望的行为和错误终止
2.即使终止执行，也要准确/无歧义的向用户展示全面的错误信息
3.错误信息有助于进行debug
正确性：程序按照spec加以执行的能力，是最重要的质量指标

区别

正确性：永不给用户错误的结果
健壮性：尽可能保持软件运行而不是总是退出
正确性倾向于直接报错(error)，健壮性则倾向于容错(fault-tolerance)
在这里插入图片描述

Reliability = Robustness + Correctness

Error and Exception in Java

所有 Exception 对象的基类是 java.lang.Throwable，以及它的两个子类 java.lang.Exception 和 java.lang.Error
在这里插入图片描述

注意：checked Exception:MUST be caught or declared to be throw

不要抛出Error对象：Error 类描述内部系统错误和资源，Java 运行时系统内的耗尽情况（例如，
VirtualMachineError, LinkageError) 很少发生– 你不应该抛出这种类型的对象

内部错误：程序员通常无能为力，一旦发生，想办法让程序优雅的结束

用户输入错误
设备错误
物理限制
在这里插入图片描述

异常：你自己程序导致的问题，可以捕获、可以处理

Exception Handling

既然Error我们无能为力，那就转向关注我们能处理的Exception
异常：
1.程序执行中的非正常事件，导致程序无法再按预想的流程执行
2.Exceptions将错误信息传递给上层调用者，并报告“案发现场”的信息
3.return之外的第二种退出途径
4.若找不到异常处理程序，整个系统完全退出

异常处理的优势

1.你不能忘记处理常见的故障模式
– 比较：使用标志或特殊返回值
2. 提供错误的高级摘要和堆栈跟踪
– 比较：C 中的核心转储
3. 改进代码结构
– 将正常代码路径与异常代码路径分开

轻松从失败中恢复的任务

轻松编写健壮、可维护的代码
反例

异常分类-从是否为RuntimeException的角度

在进行 Java 编程时，请关注异常层次结构。
异常层次结构也分为两个分支：

从 RuntimeException 派生的异常-运行时异常：由程序员在代码里处理不当造成
从 RuntimeException 继承的异常包括这样的
问题如：
其他异常：由外部原因造成
不从 RuntimeException 继承的异常包括

异常分类-从异常处理机制的角度：异常被谁check？——编译器、程序员

在这里插入图片描述

Checked Exceptions

Checked Exceptions：每个调用者都应该注意的错误并处理
 必须被捕获或传播，否则程序将无法编译（编译器检查您是否为所有检查的异常提供异常处理程序）
在这里插入图片描述
例子

发生异常时

– 您必须捕获并处理异常，或者通过声明您的方法抛出该异常来告诉编译器您无法处理它，
– 然后使用您的方法的代码将不得不处理该异常（如果无法处理，可以选择声明它抛出异常）。
– 编译器将检查我们是否完成了两件事之一（捕获或声明）

Unchecked Exceptions

Unchecked exception: Programming error, other unrecoverable failure (Error + RuntimeException)不需要（但是你也可以catch）在编译的时候用try…catch等机制处理
在这里插入图片描述
例子

发生异常时

编译器不检查错误和运行时异常
– 错误表示应用程序外部发生的情况，例如系统崩溃。运行时异常通常是由于应用程序逻辑中的错误而发生的。
– 在这些情况下你不能做任何事情，但必须重新编写你的程序代码。所以编译器不会检查这些。
– 这些运行时异常将在开发和测试中发现
时期。然后我们必须重构我们的代码来消除这些错误。

对比

在这里插入图片描述

选择哪种异常？

当要决定是采用checked exception还是unchecked exception的时候，问一个问题：“如果这种异常一旦抛出，client会做怎样的补救？在这里插入图片描述

– 不要创建没有意义的异常，client应该从checked exception中获取更有价值
的信息(案发现场具体是什么样子)，利用异常返回的信息来明确操作失败的
原因。
– 如果client仅仅想看到异常信息，可以简单抛出一个unchecked exception
1.错误可预料，但无法预防，但可以有手段从中恢复，此时使用checked
2.如果做不到这一点，则使用unchecked exception
不可预防：脱离了你的程序的控制范围

可合理的恢复

告诉调用者预测他们无法恢复的异常是没有意义的。
– 如果用户尝试从不存在的文件中读取，调用者可以提示他们输入新的文件名。
– 另一方面，如果方法由于编程错误（无效的方法参数或错误的方法实现）而失败，则应用程序无法在执行过程中解决问题。
– 它可以做的最好的事情是记录问题并等待开发人员稍后修复它
– 如果读文件的时候发现文件不存在了，可以让用户选择其他文件；但是如果
调用某方法时传入了错误的参数，则无论如何都无法在不中止执行的前提下
进行恢复。
除非您抛出的异常满足上述所有条件条件否则它应该使用Unchecked Exception.

总结

Summary
– Checked exception应该让客户端从中得到丰富的信息，以做出相应的处理。
– 要想让代码更加易读，倾向于用unchecked exception来处理程序中的错误

继承中的异常

1.如果父类型中的方法没有抛出异常，那么子类型中的方法必须捕获所有的checked exception
2.子类型方法中不能抛出比父类型方法更多的异常！

Assertions

静态检查：通过在编译时捕获它们来消除许多错误。
– 动态检查：Java 使数组溢出错误不可能通过动态捕捉它们。如果您尝试使用超出数组或列表边界的索引，Java 会自动产生错误。 —
未经检查的异常/运行时错误
– 不可变性：不可变类型是其值永远不能
创建后更改。
– 不可变值：通过 final，可以分配一次但永远不会
重新分配。
– 不可变引用：通过final，这使得引用不可重新分配，但引用指向的对象可能是可变的或不可变的