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

7.1 使用异常而非返回码

遇到错误时，最好抛一个异常，这样调用代码会很整洁，其逻辑不会被错误处理搞乱。

7.2 先写try-catch-finally语句

在编写可能抛出异常的代码时，最好先写出try-catch-finally语句。这能帮你定义改代码的用户应该期待什么，无论try代码块中执行的代码出什么错都一样。

7.3 使用未检异常

既然异常旨在让你能在较远处处理错误，那么已检异常以这种方式破坏封装简直就是一种耻辱。

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

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

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

对于代码中的某个特定区域，单一异常通常可行。伴随异常发送出来的信息能够区分不同错误。如果你想要捕获某个异常，并且放过其他异常，就是用不同的异常类。

7.6 定义常规流程

特例模式。创建一个类或者配置一个对象，用来处理特例，客户代码就不用应对异常行为。异常行为被封装到特例对象中。

7.7 别返回null值

返回null值，基本上是给自己增加工作量，也是在给调用者添乱。

7.8 别传递null值

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

如何修正？可以创建一个新异常类型并抛出。

可以使用一组断言。

7.9 小结

整洁代码是可读的，但也要强固。可读于强固并不冲突。如果将错误处理隔离看待，独立于主要逻辑之外，就能写出强固而整洁的代码。