Java使用throw抛出异常

当程序出现错误时，系统会自动抛出异常；除此之外，Java也允许程序自行抛出异常，自行抛出异常使用throw语句来完成（注意此处的throw没有后面的s，与前面声明抛出的throws是有区别的）。

1.* 抛出异常

异常是一种很“主观”的说法，以下雨为例，假设大家约好明天去爬山郊游，如果第二天下雨了，这种情况会打破既定计划，就属于一种异常；但对于正在期盼天降甘霖的农民而言，如果第二天下雨了，他们正好随雨追肥，这就完全正常。

很多时候，系统是否要抛出异常，可能需要根据应用的业务需求来决定，如果程序中的数据、执行与既定的业务需求不符，这就是一种异常。由于与业务需求不符而产生的异常，必须由程序员来决定抛出，系统无法抛出这种异常。

如果需要在程序中自行抛出异常，则应使用throw语句，throw语句可以单独使用，throw语句抛出的不是异常类，而是一个异常实例，而且每次只能抛出一个异常实例。throw语句的语法格式如下：

throw ExceptionInstance;

可以利用throw语句改写如下代码：

try {
    //将用户输入的字符串以逗号（,）作为分隔符，分隔成两个字符串
    String[] posStrArr = inputStr.split(",");
    //将两个字符串转换成用户下棋的坐标
    int xPos = Integer.parseInt(posStrArr[0]);
    int yPos = Integer.parseInt(posStrArr[1]);
    //如果用户试图下棋的坐标点已经有棋了，程序自行抛出异常
    if (!gb.board[xPos - 1][yPos - 1].equals("+")) {
        throw new Exception("您试图下棋的坐标点已经有棋了");
    }
    //把对应的数组元素赋为"●"
    gb.board[xPos - 1][yPos - 1] = "●";
} catch (Exception e) {
    System.out.println("您输入的坐标不合法，请重新输入，下棋坐标应以x，y的格式：");
    continue;
}

上面程序中“throw new Exception("您试图下棋的坐标点已经有棋了")”使用throw语句来自行抛出异常，程序认为当用户试图向一个已有棋子的坐标点下棋就是异常。当Java运行时接收到用户自行抛出的异常时，同样会中止当前的执行流，跳到该异常对应的catch块，由该catch块来处理该异常。也就是说，不管是系统自动抛出的异常，还是程序员手动抛出的异常，Java运行时环境对异常的处理没有任何差别。

如果throw语句抛出的异常是Checked异常，则该throw语句要么处于try块里，显式捕获该异常，要么放在一个带throws声明抛出的方法中，即把该异常交给该方法的调用者处理；如果throw语句抛出的异常是Runtime异常，则该语句无须放在try块里，也无须放在带throws声明抛出的方法中；程序既可以显式使用try...catch来捕获并处理该异常，也可以完全不理会该异常，把该异常交给该方法调用者处理。例如下面例子程序：

查看代码

通过上面程序也可以看出，自行抛出Runtime异常比自行抛出Checked异常的灵活性更好。同样，抛出Checked异常则可以让编译器提醒程序员必须处理该异常。

1.* 自定义异常类

在通常情况下，程序很少会自行抛出系统异常，因为异常的类名通常也包含了该异常的有用信息。所以在选择抛出异常时，应该选择合适的异常类，从而可以明确地描述该异常情况。在这种情形下，应用程序常常需要抛出自定义异常。

用户自定义异常都应该继承Exception基类，如果希望自定义Runtime异常，则应该继承RuntimeException基类。定义异常类时通常需要提供两个构造器：一个是无参数的构造器；另一个是带一个字符串参数的构造器，这个字符串将作为该异常对象的描述信息（也就是异常对象的getMessage()方法的返回值）。

下面例子程序创建了一个自定义异常类：

查看代码

上面程序创建了AuctionException异常类，并为该异常类提供了两个构造器。尤其是创建带一个字符串参数的构造器，其执行体也非常简单，仅通过super来调用父类的构造器，正是这行super调用可以将此字符串参数传给异常对象的message属性，该message属性就是该异常对象的详细描述信息。

如果需要自定义Runtime异常，只需将AuctionException.java程序中的Exception基类改为RuntimeException基类，其他地方无须修改。

提示：在大部分情况下，创建自定义异常都可采用与AuctionException.java相似的代码完成，只需改变AuctionException异常的类名即可，让该异常类的类名可以准确描述该异常。

1.* catch和throw同时使用

前面介绍的异常处理方式有如下两种：

• 在出现异常的方法内捕获并处理异常，该方法的调用者将不能再次捕获该异常。
• 该方法签名中声明抛出该异常，将该异常完全交给方法调用者处理。

在实际应用中往往需要更复杂的处理方式，当一个异常出现时，单靠某个方法无法完全处理该异常，必须由几个方法协作才可完全处理该异常。也就是说，在异常出现的当前方法中，程序只对异常进行部分处理，还有些处理需要在该方法的调用者中才能完成，所以应该再次抛出异常，让该方法的调用者也能捕获到异常。

为了实现这种通过多个方法协作处理同一个异常的情形，可以在catch块中结合throw语句来完成。如下例子程序示范了这种catch和throw同时使用的方法：

查看代码

上面程序“bid(String bidPrice)”对应的catch块捕获到异常后，系统打印了该异常的跟踪栈信息，接着抛出一个AuctionException异常，通知该方法的调用者再次处理该AuctionException异常。所以程序中的main方法，也就是“bid(String bidPrice)”方法调用者还可以再次捕获AuctionException异常，并将该异常的详细描述信息输出到标准错误输出。

提示：这种catch和throw结合使用的情况在大型企业级应用中非常常用。企业级应用对异常的处理通常分成两个部分：应用后台需要通过日志来记录异常发生的详细情况；应用还需要根据异常向应用使用者传达某种提示。在这种情形下，所有异常都需要两个方法共同完成，也就必须将catch和throw结合使用。

1.* Java 7增强的throw语句

对于如下代码：

try {
    new FileOutputStream("a.txt");
} catch (Exception ex) {
    ex.printStackTrace();
    throw ex;
}

上面代码片段中的“throw ex”代码再次抛出了捕获到的异常，但这个ex对象的情况比较特殊：程序捕获该异常时，声明该异常的类型为Exception；但实际上try块中可能只调用了FileOutputStream构造器，这个构造器声明只是抛出了FileNotFoundException异常。

在Java 7以前，Java编译器的处理“简单而粗暴”，由于在捕获该异常时声明ex的类型是Exception，因此Java编译器认为这段代码可能抛出Exception异常，所以包含这段代码的方法通常需要声明抛出Exception异常。例如如下方法：

查看代码

从Java 7开始，Java编译器会执行更细致的检查，Java编译器会检查throw语句抛出异常的实际类型，这样编译器知道“throw ex”代码处实际上只可能抛出FileNotFoundException异常，因此在方法签名中只要声明抛出FileNotFoundException异常即可。即可以将代码改为如下形式：

查看代码

1.* 异常链

对于真实的企业级应用而言，常常有严格的分层关系，层与层之间有非常清晰的划分，上层功能的实现严格依赖于下层的API，也不会跨层访问。下图显示了这种具有分层结构应用的大致示意图：

对于一个采用图所示结构的应用，当业务逻辑层访问持久层出现SQLException异常时，程序不应该把底层的SQLException异常传到用户界面，有如下两个原因：

• 对于正常用户而言，他们不想看到底层SQLException异常，SQLException异常对他们使用该系统没有任何帮助。
• 对于恶意用户而言，将SQLException异常暴露出来不安全。

把底层的原始异常直接传给用户是一种不负责任的表现。通常的做法是：程序先捕获原始异常，然后抛出一个新的业务异常，新的业务异常中包含了对用户的提示信息，这种处理方式被称为异常转译。假设程序需要实现工资计算的方法，则程序应该采用如下结构的代码来实现该方法：

public calSal() throws SalException {
    try {
        //实现结算工资的业务逻辑
        ...
    } catch (SQLException sqle) {
        //把原始异常记录下来，留给管理员
        ...
        //下面异常中的message就是对用户的提示
        throw new SalException("访问底层数据库出现异常");
    } catch(Exception e) {
        //把原始异常记录下来，留给管理员
        ...
        //下面异常中的message就是对用户的提示
        throw new SalException("系统出现未知异常");
    }
}

这种把原始异常信息隐藏起来，仅向上提供必要的异常提示信息的处理方式，可以保证底层异常不会扩散到表现层，可以避免向上暴露太多的实现细节，这完全符合面向对象的封装原则。

这种把捕获一个异常然后接着抛出另一个异常，并把原始异常信息保存下来是一种典型的链式处理（23种设计模式之一：职责链模式），也被称为“异常链”。

在JDK 1.4以前，程序员必须自己编写代码来保持原始异常信息。从JDK 1.4以后，所有Throwable的子类在构造器中都可以接收一个cause对象作为参数。这个cause就用来表示原始异常，这样可以把原始异常传递给新的异常，使得即使在当前位置创建并抛出了新的异常，你也能通过这个异常链追踪到异常最初发生的位置。如果我们希望上面的SalException可以追踪到最原始的异常信息，则可以将该方法改写为如下形式：

public calSal() throws SalException {
    try {
        //实现结算工资的业务逻辑
        ...
    } catch (SQLException sqle) {
        //把原始异常记录下来，留给管理员
        ...
        //下面异常中的sqle就是原始异常
        throw new SalException(sqle);
    } catch (Exception e) {
        //把原始异常记录下来，留给管理员
        ...
        //下面异常中的e就是原始异常
        throw new SalException(e);
    }
}

上面程序中代码创建SalException对象时，传入了一个Exception对象，而不是传入了一个String对象，这就需要SalException类有相应的构造器。从JDK 1.4以后，Throwable基类已有了一个可以接收Exception参数的方法，所以可以采用如下代码来定义SalException类：

public class SalException extends Exception {
    public SalException(){}
    public SalException(String msg) {
          super(msg);
    }
    //创建一个可以接收Throwable参数的构造器
    public SalException(Throwable t) {
          super(t);
    }
}

创建了这个SalException业务异常类后，就可以用它来封装原始异常，从而实现对异常的链式处理。