第7章-错误处理

错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法

7.1 使用异常而非返回码

遇到错误时，最好抛出一个异常。使调用代码整洁，逻辑不乱。

7.2 先写Try-Catch-Finally

编写可能出现异常的代码时，先写try-catch-finally。

7.3 使用不可控异常

使用 checked exception 违反开闭原则。所以尽量使用not checked exception

7.4 给出异常发生的环境说明

你抛出的每一个异常，都应当提供足够的环境说明。（表明你该失败操作的初衷）

7.5 依调用者需要定义异常类

调用一些第三方API时要catch的异常种类是第三方API为了自己的代码而定义的异常类，作为调用者应该自己打包第三方API返回的异常类型（就是重新封装一层），以降低依赖。可以平移替换第三方API

7.6 定义常规流程

有时候抛异常的方式会打断一些正确的业务逻辑。那么我们可以创建一个类或配置一个对象，用来处理特例，将异常行为封装到特例对象中。这种手法叫做特例模式。

7.7 别返回null值

返回null值就是给自己增加工作量，后续的调用代码要做很多的null判断，毫无意义。而且一旦没有做判断就会空指针异常。所以我们应该尽量不返回null，抛出异常、返回特例对象、返回Collections.emptyList()...

7.8 别传递null值

除非API要求你传递null值，否则你尽可能不传递null值。

小结

整洁代码是可读的，但也要强固。可读与强固并不冲突。如果将错误处理隔离看待，独立于主要逻辑之外，就能写出强固而整洁的代码。做到这一步，我们就能单独处理它，也极大地提升了代码的可维护性