代码整洁之道-第7章 错误处理

《代码整洁之道》第7章-错误处理

错误处理只不过是编程时必须要做的事之一。输入可能出现异常，设备可能失效。简言之，可能会出现错误，当错误发生时，程序员就有责任确保代码照常工作。

编写既整洁又强固的代码—雅致的处理错误代码的技巧和思路。

7.1 使用异常而非返回码

以前，没有异常处理机制时：（这类手段的问题在于，他们搞乱了调用者代码。调用者必须在调用之后即刻检查错误，不幸的是，这个步骤很容易被遗忘。）

设置一个错误标识；

返回给调用者检查的错误码；

有异常处理机制后：（遇到错误时，最好抛出一个异常。调用代码很整洁，绮逻辑不会被错误处理搞乱。）

使用异常机制来处理错误。

7.2 先写Try-Catch-Finally语句

它们在程序中定义了一个范围。执行try-catch-finally语句中try部分的代码时，表明可以随时取消执行，并在catch语句中接续。

7.3 使用不可控异常

C#, C++, Ruby, Pyth 都不支持 可控异常，Java支持。

使用可控异常的代价是：违反“开放/闭合原则”。如果你在方法中抛出可控异常，而catch语句在三个层级一上，你就得在catch语句和抛出异常处之间的每个方法签名中声明该异常。

所以，尽量使用 不可控异常。

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

抛出的每个异常，都应该提供足够的环境说明，以便判断错误的来源和处所。

Java中，可以从任何异常那里得到“堆栈踪迹（stack trace）”；

应创建信息充分的错误消息（包括失败的操作和失败类型），并和异常一起传递出去。（如果有日志系统，可以传递足够的信息给catch块，并记录下来。）

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

对于代码的某个特定区域，单一异常类通常可行。伴随异常发送出来的信息能够区分不同错误。

如果你想要捕获某个异常，并且放过其他异常，就使用不同的异常类。

打包第三方API：

当你打包第三方API，就降低了对它的依赖：未来你可以不太痛苦的改用其他代码库。在你测试自己的代码时，打包也有助于模拟第三方调用。

打包的好处还在于，你不必绑死在某个特定厂商的API设计上。你可以定义自己感觉舒服的API。

7.7 别返回null值

错误处理中，容易引发错误的做法，第一个就是返回null值。

曾经见过很多几乎每行代码都在检查null值。

返回null值，基本上是在给自己增加工作量，也是在给调用者添乱。只要有一处没检查null值，应用程序就会失控。（在运行时得到一个NullPointerException异常）。

特例对象是良药。与其返回null值，不如返回一个特例对象—空列表（Collections.emptyList()）。

7.8 别传递null值

在方法中返回null值是糟糕的做法，但将null值传递给其他方法就更 糟糕了。

判断是否为null；

使用断言assert；

看上去很美，单仍未解决问题。如果传入null值，还是会得到运行时错误。

在大多数编程语言中，没有良好的方法能对付由调用者意外传入的null值。恰当的做法是，禁止传入null值。