错误处理

使用非受检异常

受检异常每个方法的签名都列出它可能传递给调用者的异常。如果签名与代码实际所做之事不符，或者调用者忽略了异常处理，代码在字面上就无法编译。

代价是如果你在方法中拋出可控异常，而catch语句在三个层级之上，你就得在catch语句和抛出异常处之间的每个方法签名中声明该异常。这意味着对软件中较低层级的修改，都将波及较高层级的签名。抛出受检异常路径中的每个函数都要去了解下一层级的异常细节，捕获该异常，或在其签名中添加合 适的throw子句。打破了封装。

如何使用非受检异常：自定义异常类继承RuntimeException。

给出异常发生的环境说明

抛出的每个异常，都应当提供足够的环境说明，以便判断错误的来源和处所。有时候java异常的堆栈追踪无法提供失败的原因，应创建信息充分的错误消息，并和异常一起传递出去。在消息中，包括失败的操作和失败类型并记录到系统日志中。

依调用者需要定义异常类

如何自定义错误类？对错误分类有很多方式，最重要的是考虑它如何被捕获。如果一个方法可能抛出多种异常，而客户端对这些异常捕获处理的方式都大同小异，那么异常捕获代码会出现冗余。

如果调用第三方API需要以相同方式处理大量的异常，可以先对将第三方API进行打包，在一个接口中统一调用第三方API，捕获可能的异常并抛出统一的自定义异常，这样调用处只需要调用统一接口，处理自定义异常即可，从而写出简洁的代码。打包第三方API还可以降低对它的依赖：未来你可以不太痛苦地 改用其他代码库。

错误处理不要混杂业务逻辑

对于特殊的业务逻辑，如果可以用if判断实现，不要走异常，不要抛出一个自定义异常，在捕获是走特殊的业务逻辑，异常只用在可预见又无法掌控的情况。

别返回null值

返回null值，是在给调用者添乱，调用者不得不小心的做空指针检查，如果大意，可能出现空指针异常。如果你打算在方法中返回null值，不如抛出异常，或是返回特例对象（如空列表，空字符串）。如果你在调用某个第三方API中可能 返回null值的方法，可以考虑用新方法打包这个方法，在新方法中抛出异常或返回特例对象。

别传递null值

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