错误处理

使用异常而非返回码

如果使用返回码供检查错误，它们会扰乱调用者的代码，调用者必须在调用之后立刻检查错误，所以遇到错误时，最好抛出一个异常，调用者的代码不会被扰乱。

先写 Try-Catch-Finally 语句

try 代码块表明是可以随时取消执行的，并在 catch 语句中接续。try 代码块就像是事务。catch 代码块将程序维持在一种持续状态，无论 try 代码块中发生了什么，这能定义代码的用户应该期待什么。

使用不可控异常

可控异常：每个方法的签名都列出它可能传递给调用者的异常。

可控异常违背了开放-封闭原则，如果在一个方法中抛出了可控异常，将影响到较高层级的方法签名，修改好的模块必须重新构建。

如果是编写一套关键代码库，则可控异常有时也会有用：必须捕获异常。但对于一般的应用开发，其依赖成本要高于收益。

给出异常发生的环境说明

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

依调用者需要定义异常类

处理异常时可能出现很多重复代码，需要对每个异常单独处理，可以对所有的异常进行打包成一个类，根据异常的信息区分不同的错误，如果是将第三方API打包，可以降低与这个代码库的耦合度。

定义常规流程

异常如果打断了业务逻辑，可以使用特例模式，创建一个类或配置一个对象用来处理特例，异常行为被封装到特例对象中。

别返回 null 值

如果返回了 null 值，在调用这个方法的时候必须时刻注意 null 值的判断，一旦忘记进行捕获，可能造成影响。在没有必要返回 null 值的时候，可以返回值为空的对象。

别传递 null 值

除非 API 要求向它传递 null 值，否则就要尽量避免传递 null 值。

小结

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