Java语言精粹之三：异常系统

使用Java的异常通常都有以下困惑：
1、 不知道怎么处理异常
2、 直接忽略异常，统统throw
3、 简单的catch住，然后e.printStaceTree()
4、 处理了异常，但使得代码凌乱，主线代码不清晰

在正确的使用异常前，先了解下Java异常。异常的基类为Throwable。 Throwable和Return有些许类似，Return的作用是从一个方法返回到调用方，然后继续顺序执行代码，Throwable的作用是以抛出异常的形式来返回调用方，但不是顺序执行，而是从异常处理块处继续执行。比如：

public void test() {
  try {
    work();
    log("done!");
  } catch (Throwable e) {
    log("error prompt", e);
    rework();
  }
}

上述代码会先执行work()，如果顺利执行则会打印 done!，如果work()内部出现异常，则会跳到异常处理块，记录异常信息，然后调用rework()，而不会打印 done!，这样代码就从主流程转向了异常处理，或者说错误处理的流程。

在那些没有异常的语言中，比如C，常常见到这样的情况，返回一个特定的值（0/-1）来表示错误，作为调用方需要搞清楚方法返回什么表示出错了。为了处理错误，我们还要在调用方法后马上检查返回值是不是0/-1，是怎么办，不是又怎么办，这样错误的处理流程和正确的处理流程又紧密的耦合在了一起。这样的代码无论是维护，还是扩展都非常困难的，所以也有人索性忽略错误处理。只关注或主要关注正确的流程。在Java的开发者中，也存在着那么一批人，从来不理会异常。如果你也是那么做的，就请赶紧停下这罪恶的行径，认真地体会异常系统的思想和优势。

Java异常机制的思想是：错误处理应该从非错误的主线代码流程中分离出去，且指示错误的方式应该是显式的，而不是依靠返回值的使用习惯。方法的返回值应该是它正常、无错地完成时产生的结果。如果有错误发生，那些代码应该放在别处，并关联到一个能指出是什么错误的对象上。

文章的开始有提到Java异常和Return类似，都能从方法中返回，但什么时候应该使用Return返回，什么时候应该用异常来返回（抛出）呢？异常返回的是出乎预料、让人很惊讶的结果，而Return返回的正常的结果。举个例子，我们出去吃饭，正常的情况下饭菜可口，三下五除二就吃完了，或者菜难吃点，磨磨唧唧地吃完。但是如果正当你吃的不亦乐乎的时候，突然发现白色的米饭粒里夹着一粒黑乎乎的老鼠屎，这就是异常情况。
当你看到这粒老鼠屎后，你可以自由选择处理老鼠屎（异常）的方式：
1、把老鼠屎丢一边继续吃，我们称这样的系统容灾性很强
2、恶心吃不下去，结帐走人，这叫因异常抛出而放弃业务的继续处理
3、找相关人员处理，这叫业务流程的异常处理方式
4、把桌子掀了……这是错误发生时的蝴蝶效应，一个业务的异常导致其他业务不能正常使用
5、其他情况
还有一种方式，就是不管有没有老鼠屎都照吃，这就是不处理异常的方式。

Java的异常经常被人滥用，常见的滥用方式有以下几种：
1、 对每个会抛出异常的代码分别catch住。

public void test() {
  try {
    execSql1();
  } catch (SQLException e) {
    log("error prompt", e);
  }
  try {
    execSql2();
  } catch (SQLException e) {
    log("error prompt", e);
  }
  //to other things…
}

除非你不希望execSql1()的执行影响到execSql2()的执行（比如关闭流的时候），否则不应该这么做，这样不是很好的分离主线代码/错误代码的方式，改进：

public void test() {
  try {
    execSql1();
    execSql2();
  } catch (SQLException e) {
    log("error prompt", e);
  }
  //to other things…
}

2、 先catch了异常类A，然后再catch异常类A的子类

public void test() {
  try {
    execSql();
  } catch (Exception e) {
    // 执行一些动作
  } catch (SQLException e) {
    // 执行其他动作
  }
}

SQLEXCEPTION是EXCEPTION的子类，这里由于先catch住了EXCETPION，也就包括了SQLEXCEPTION，第二个catch子句永远都不会执行了。千万不要这么做，这样的错误很难查出。改进：

public void test() {
  try {
    execSql();
  } catch (SQLException e) {
    // 执行一些动作
  } catch (Exception e) {
    // 执行其他动作
  }
}

3、 简单的打印异常或忽略异常

public void test() {
  try {
    execSql();
  } catch (Exception e) {
    // 什么也不做
  } 
  try {
    doOtherThing();
  } catch (Exception e) {
    e.printStackTrace()
  } 
}

如果什么都不打印是最邪恶的处理方式，因为在运行环境中没有提示信息，你可能根本不知道错误在哪里。仅仅打印到控制台也不可取，因为你收到错误的时间可能距离错误发生的时间已经过去了好几个小时，而控制台的信息很可能被别的信息覆盖（window平台），也可能因为太大而无法查阅（linux平台）。改进：应该采用日志形式输出，比如log4j等等。

Exception&RuntimeException
Throwable有两个子类，Exception和RuntimeException。如果你抛出了Exception，那么意味着你要在方法签名里申明异常，并且在调用该方法时必须处理可能抛出的异常，否则就不能通过编译。这看起来好像很麻烦，但是Java提供了另一种异常RuntimeException，你不需要申明，也可以不处理，这看起来好像又很方便，于是部分程序员将所有抛出的异常都定义成RuntimeException子类，把不是RuntimeException的异常包装成RuntimeException，并认为自己巧妙的运用了异常。如果你也是这么做的，那就需要了解一下RuntimeException设计的初衷，明白什么时候才要使用它。

最初设计异常系统的时候，人们担心程序在运行期间会因为硬件问题、JVM的bug、安全等而产生异常，这种异常通常是应用程序无法处理的。为了将这类无法处理的问题和一般性问题区分开，于是Java提供了RuntimeException，这中异常无需声明，也不用处理，以保持程序的简洁。但是我们不能因为RuntimeException这种便利性而盲目的使用它，大部分异常还是需要声明，也需要处理的，是因为这是你应该做的，只有这样做才能保证程序的健壮性。

作者思路：
1、 异常的使用方法，和return的比较
2、 描述异常的设计理念
3、 举例描述异常如何工作
4、 列举异常不规范的使用方式
5、 RuntimeException的由来、使用探讨

后话：
我感觉作者是明显反对RuntimeException，提倡Exception的使用，但是我觉得还是Java异常系统设计的不够得体，当然也可能是我太菜没领会到精髓。我认为，一般抛出的异常应用程序一般都无法处理，只能记录错误，并通过修正源代码来解决。但是Java异常系统可以有效地分离主线代码和异常处理代码，提供足够的调试信息，我觉得这才是它实用的地方。