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

概述

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

在本章中,我将概要列出编写既整洁又强固的代码——雅致地处理错误代码的一些技巧
和思路

1. 使用异常而非返回码

在很多以前的语言中（不像java这种异常处理机制），或者错误的写法中，存在有些代码的方法通过返回码判断错误逻辑，这显然是非常严重的错误。eg:

2. 先写Try-Catch-Finally语句

异常的妙处之一是,它们在程序中定义了一个范围。执行 try-catch- finally语句中try部分的代码时,你是在表明可随时取消执行,并在 catch语句中接续。

这样做的好处在于：易于清晰代码逻辑，控制事务范围。

3. 给出异常发生的环境说明

你抛出的每个异常,都应当提供足够的环境说明,以便判断错误的来源和处所。在Java中，你可以从任何异常里得到堆栈踪迹( stack trace);然而,堆栈踪迹却无法告诉你该失败操作的初衷。

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

4. 包装异常的类型

假如调用者，依赖于第三方API，此API会抛出各种异常，如果由客户代码处理就会写出很多catch语句块，如下图：

这种时候我们可以将这个接口包装，抛出一个统一的异常类，方便客户代码处理。

这也是外观模式的应用之一。

5. 定义系统常规异常处理

如果是一些常规的系统异常，如果不用客户代码处理的就尽量在底层做好处理。

6. 别返回NULL值

可以敷衍说上列代码的问题是少做了一次null值检查,其实问题多多。如果你打算在方法中返回nu值,不如抛出异常,或是返回特例对象。如果你在调用某个第三方API中可能返回null值的方法,可以考虑用新方法打包这个方法,在新方法中抛出异常或返回特例对象。

在许多情况下,特例对象都是爽口良药。设想有这么一段代码：

现在, get Exployees可能返回null,但是否一定要这么做呢?如果修改 getEmployee,返回空列表,就能使代码整洁起来：

此条特别适用于返回List这种集合类的，单个对象的需要视情况而定—返回null或者抛出异常都要给到足够的方法说明。

最后的话

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