第 7 章 错误处理

7.1 使用异常而非返回码

在很久以前，许多语言都不支持异常。这些语言处理和汇报错误的手段都有限。你要么设
置一个错误标识，要么返回给调用者检查的错误码。代码清单7-1中的代码展示了这些手段。

// 代码清单7-1 DeviceContollerjava
public class DeviceController {
 	... 
  public void sendShutDown{) {
    DeviceHandle handle = getHandle(DEV1);
    // Check the state of the device
    if (handle != DeviceHandle.INVALID) {
    	// Save the device status to the record field
    	retrieveDeviceRecord(handle);
      // If not suspended, shut down
      if (record.getStatus() != DEVICE_SUSPENDED) {
      	pauseDevice(handle) ;
      	clearDeviceWorkQteue(handle) ;
      	closeDevice(handle) ;
      } else {
      	logger.log ("Device suspended. Unable to shut down") ;
      }
    } else {
      logger.log ("Invalid handle for: " + DEV1.toString());
    }
   }
	...    
}

这类手段的问题在于，它们搞乱了调用者代码。调用者必须在调用之后即刻检查错误。不幸的是，这个步骤很容易被遗忘。所以，遇到错误时，最好抛出一个异常。调用代码很整洁，其逻辑不会被错误处理搞乱。
代码清单 7-2 展示了在方法中遇到错误时抛出异常的情形。

// 代码清单7-2 DeviceController.java (采用异常处理)
public class DeviceController {
  ...
  public void sendShutDown() {
    try {
      tryToShutDown();
    } catch (DeviceShutDownError e) {
      logger.log(e);
    }
	}
  
  private void tryToShutDown() throws Devi ceShut DownError {
    DeviceHandle handle = getHandle(DEV1);
    DeviceRecord record = retrieveDeviceRecord(handle);
    pauseDevice(handle);
    clearDeviceWorkQueue(handle);
    closeDevice(handle);
	}
  
  private DeviceHandle getHandle (DeviceID id) {
    ...
    throw new DeviceShutDownError ("Invalid handle for: " + id. toString()) ;
    ...
  }
  ...
}

注意这段代码整洁了很多。这不仅关乎美观。这段代码更好，因为之前纠结的两个元素设备关闭算法和错误处理现在被隔离了。你可以查看其中任一元素，分别理解它。

7.2 先写 Try-Catch-Finally 语句

异常的妙处之- -是，它们在程序中定义了一个范围。执行 try-catch-finally 语句中 try 部分的代码时，你是在表明可随时取消执行，并在 catch 语句中接续。
在某种意义上，try 代码块就像是事务。catch 代码块将程序维持在一种持续状态， 无论 try 代码块中发生了什么均如此。所以，在编写可能抛出异常的代码时，最好先写出 try-catch-finally 语句。这能帮你定义代码的用户应该期待什么，无论 try 代码块中执行的代码出什么错一样。

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

你抛出的每个异常，都应当提供足够的环境说明，以便判断错误的来源和处所。在 Java 中，你可以从任何异常里得到堆栈踪迹(stack trace)；然而，堆栈踪迹却无法告诉你该失败操作的初衷。
应创建信息充分的错误消息，并和异常一起传递出去。在消息中，包括失败的操作和失败类型。如果你的应用程序有日志系统，传递足够的信息给 catch 块，并记录下来。

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

对错误分类有很多方式。可以依其来源分类:是来自组件还是其他地方?或依其类型分
类:是设备错误、网络错误还是编程错误?不过，当我们在应用程序中定义异常类时，最重
要的考虑应该是它们如何被捕获。
来看一个不太好的异常分类例子。下面的try-catch-finally语句是对某个第三方代码库的
调用。它覆盖了该调用可能抛出的所有异常:

ACMEPort port = new ACMEPort(12) ;

try {
	port.open() ;
} catch (DeviceResponseException e) {
	reportPortError(e) ;
	logger.log("Device response exception", e);
} catch (ATM1212UnlockedException e) {
	reportPortError(e) ;
	logger.log("Unlock exception", e);
} catch (GMXError e) {
	reportPortError(e);
	logger.log("Device response exception") ;
} finally {
	...
}

语句包含了一大堆重复代码，这并不出奇。在大多数异常处理中，不管真实原因如何，我们总是做相对标准的处理。我们得记录错误，确保能继续工作。

7.7 别返回 null 值

这种代码看似不坏，其实糟透了!返回 null 值，基本上是在给自己增加工作量，也是在给调用者添乱。只要有一处没检查 null 值，应用程序就会失控。

对于从应用程序深处抛出的 NullPointerException 异常，你到底该作何反应呢?

7.8 别传递 null 值

在大多数编程语言中，没有良好的方法能对付由调用者意外传入的 null 值。事已如此, 恰当的做法就是禁止传入 null 值。这样，你在编码的时候，就会时时记住参数列表中的 null 值意味着出问题了，从而大量避免这种无心之失。