Java异常

 

异常处理机制是Java许多特性的重要基础。Java采用面向对象的方式来处理异常。本文介绍与异常相关的内容。

1. 什么是异常？

异常是异常事件 （exceptional event）的简写，是程序运行过程中出现的打断（disrupt）正常运行的事件，比如被除数为0导致的程序异常。当程序的方法出现异常时，方法就会创 建一个描述该异常的对象，将这个异常对象传递给运行时系统（runtime system）。这个对象叫做异常对象，它包含描述异常的信息、异常类型、出现异常是程序的状态等等。创建异常对象并将其交给运行时系统就叫做抛出异常。

我们知道，方法的调用是一环扣着一环的，来自相同或者不同对象的方法调用形成一个链条，如下图：

这个方法链就叫做调用栈 （call stack）。而栈踪迹（stack trace）提供更多异常的信息，如当前线程的执行历史，异常发生时一个类列表和方法列表。我们常用printStackTrace( )方法或者printStackTrace(PrintStream)、printStackTrace(PrintWriter)来打印栈踪迹。异常抛 出后，沿着这个调用栈的反方向依次查找能够处理此类型异常的异常处理代码（exception handler）。如下图所示：

方法可以选择自己处理异 常，也可以继续传递异常，甚至可以重新抛出异常。无论哪种方式，异常总会在某个点被捕捉并处理，如果所有方法都没有对异常进行处理，程序就终结。异常可以 由虚拟机生成，也可以通过代码手动生成。虚拟机抛出的异常一般与语言规则（如除数为0）或者运行环境相关（比如内存溢出）的基础性错误有关，而手动抛出的 异常一般用于向方法的调用者报告一些错误条件（如参数范围不对）。

2. 两种异常处理方式

异常抛出后，java提 供2种方式对其进行处理。一种是使用try语句捕获异常并对异常进行处理，通过try、catch、finally这三个关键字来实现。另一种是使用关键 字throws在方法声明时指定（specify）它可能抛出的异常类型。需要指出的是，并不是所有的异常都必须被处理或者指定，为了理解为什么是这样， 我们有必要学习一下异常的类型。

3. 异常类型

所有的异常都是内置的 Throwable类的子类。所以，虚拟机抛出的所有异常类型必须是Throwable及其子类的实例，使用throw。throws抛出的异常也必须这 样，catch子句中的参数也必须是Throwable类及其子类的实例。Throwable有两个直接子类，Exception和Error。 Exception有一个重要子类是RuntimeException。基于这样的继承关系，我们把异常分为三类：

3.1 error

这种类型的错误一般是程 序之外的，而且很难预测和恢复。例如，程序成功打开了一个文件准备读取内容，但是由于硬件或者其他因素导致无法成功读取文件内容，这时候会抛出一个 java.io.IOError。我们可以选择处理这种类型的异常，以提醒用户出现什么问题，也可以打印堆栈然后退出。这种类型的异常有Error及其子 类来表示。我们可以不处理（捕捉或者指定）这类异常，通常也无法处理（因为不可预测），一般由虚拟机抛出，比如堆栈溢出就是一种error。

3.2 runtime exception

这类异常是程序自身导致 的，通常有程序bug引起，比如创建Filereader对象时，我们传递了文件名给构造器，但是如果由于程序本身的原因导致传递null给构造器，这时 候程序会抛出NullPointerException。程序可以捕捉这类异常，但是更有意义的做法也许是找出bug，修正程序。这类异常有 RuntimeException及其子类表示，java不强制要求对这种类型的异常进行处理。

error和 runtime exception合起来称为unchecked exception，之所以这么称呼，是因为编译器不检查方法是否处理或者抛出这两种类型的异常。因此编译期间出现这种类型的异常也不会报错，所以我们可 以不处理这些异常。而是由虚拟机提供默认的处理程序。

3.3 checked exception：

除了error和 runtime exception这两种类型的异常外，其他的异常都称为checked 异常，优秀的程序必须预测到这些异常并从中恢复过来。再次以读取文件为例，加入现在的文件名是由用户输入的，正常情况下我们假设用户输入的文件存在并且可 读的，然后程序正常运行。但是用户完全有可能输入一个不存在的文件名，这时候程序抛出FileNotFoundException，好的程序必须捕捉这类 异常，然后提醒用户。对于这种类型的异常，我们的代码必须处理(try)或者抛出(指定)异常(throws)。

4. 使用try catch finally处理异常

对于checked类型异常，我们要么对它进行处理要么在方法头使用throws抛出。这一部分介绍第一种方法。try语句一般结构如下代码所示：

 

              try {
    // code could throw an exception
    // risky code
} catch (IOException name) {

} catch (Exception name) {
    // do something with exception
} catch (Throwable name) {
    // do
} finally {
    // clean up

}

4.1 try：

首先把可能抛出异常的代码块放在try语句当中，当然你可能把可能抛出unchecke异常甚至不会抛出异常的代码放进try语句中。

4.2 catch

紧接着是一个或者多个的 catch语句，catch语句的参数为可能抛出的异常类型，catch语句用于处理异常。将抛出的异常类型与catch参数中的类型进行匹配，如果符 合，则执行匹配的catch语句。所谓匹配，就是看能否将抛出的异常对象赋值给参数中异常类型的变量。执行完匹配的catch语句之后，其他catch语 句就会被忽略掉。这跟switch语句中的case情况不一样，case语句中如果没有break，则会继续执行下一个case。在catch语句中可以 做很多工作，从简单地输出信息，或者提醒用户做出决定，甚至使用链式异常将异常传递给更高一级的异常处理程序。

关于catch有几点需 要说明：1）参数的异常类型必须是Throwable类或者其子类。2）从上往下的catch语句，其参数类型必须按照从子类到父类顺序，因为一旦匹配到 一个类型，catch语句捕获这个超累及其所有子类的异常，然后忽略往后的catch，也就意味着排在后面的子类用于不会到达，java中不可到达的代码 被认为是错误的。3）可以有一个或者多个catch语句，甚至如果有finally语句的情况下，可以没有catch语句。 

想要捕获多个异常，可以使用多个catch语句，JDK7以后提供了另外一种方式：多重捕获（multi-catch)。其格式如下：

catch（ExceptionType1 | ExceptionType2 exception） { ... }

每个异常类型用“|”分隔开，需要注意的是，使用这种方式的catch时，catch参数被自动设为final，因此不能赋予新值。下面是一个例子：

 

catch (IOException|SQLException ex) {
    logger.log(ex);
    throw ex;
}

 

4.3 finally

finally中的代码总是会被执行，除非在执行try或者catch语句时虚拟机退出（System.exit(1)),因此可以在finally里面放置一些收尾工作的代码（clean up）， 诸如关闭文件等。这样，即使执行try或者catch语句的时候遇到break、return、continue，finally的代码块依然会被执行 （在方法返回之前执行）。需注意的是，如果执行try或者catch语句的线程被打断（interrupted）或者被杀死 （killed），finally语句就不会执行。当操作文件或者其他流的时候，在finally关闭流是一种不错的方式。当然也可以使用Java 7以后带资源的try。

finally语句不是必须的，也就是说try catch finally有三种组合：1）try catch finally 2) try catch 3)try finally。  

4.4 几点说明：

1）try语句中可能出现的异常，可以在catch语句中全部捕获处理，也可以只捕获处理一部分另外的留给throws处理。甚至可以全部不捕获，全部交由throws处理，只在finally中做一些clean up工作。

2）如果try中没有异常抛出，则不执行任何catch语句。如果出现在catch参数中生命的异常类型，则执行对应的catch语句，忽略其他语句。如果抛出了catch中没有声明的异常，会在throws中抛出。finally总会被执行。

3）try和catch语句中定义的变量都是局部变量，语句块结束之后就会消失，因此如果想在后续继续使用变量，要在try语句之前声明。

4）如果在try block和finally block中都执行return语句，那么最终返回的是finally block的return值。例如下面的方法：

 

public static int go(int choice) {

    try {

        if (choice == 1)
            System.out.println("Hello " + "Your name");
        else if (choice == 2)
            System.out.println("1 / 0 =  " + 1 / 0);
        else if (choice == 3)
            return 3;
        else if (choice == 4)
            System.exit(1);
        else if (choice == 5)
            System.out.println("1 / 0 =  " + 1 / 0);
        else if (choice == 6)
            return -1;
    } catch (NumberFormatException e) {
        System.out.println("Number Format Exception occurred");
    } finally {
        System.out.println("Goodbye from finally block");
        if (choice == 5)
            return 5;
        if (choice == 6)
            return 6;
    }
    return 0;
}

如果choice=6，则在try语句中返回-1，在finally中返回6，最终返回的是6.

5）如果一个没有被捕获 的异常出现，并且从finally block中return，那么这个没有被捕获的异常会被丢掉。比较上面例子中的choice=2和5.2和5它们都抛出 ArithmeticException（unchecked），但是如果choice=2，finally block不会执行return语句，所以异常会被抛出。而如果choice=5，那么finally block将执行return 5；语句，所以异常被丢掉，不会抛出。（可以运行验证）

5. 嵌套try和带资源的try

5.1 嵌套try语句：

一条try语句可以嵌套在两外一条try语句中，例如：

 

try {
            // code could throw an exception
            // risky code
            //System.exit(1);
            try {

            } catch (IndexOutOfBoundsException | Error e) {
                // do something
            }

            throw new IOException();
        } catch (IOException name) {
            // do something with exception
            // nested try
            try {

            } catch (RuntimeException e) {

            }
        } catch (Throwable name) {
            // do
        } finally {
            // clean up
            System.out.println("clean up");
            try {

            } catch (Throwable t) {

            }

        }

    }

使 用嵌套try的时候，尤其要注意catch参数类型顺序的问题，否则容易出现不可到达的代码。另外有一种比较隐蔽的嵌套try。比如在一个try语句中调 用另外一个方法，而这个方法内部又有一条try语句。方法中的try语句会被嵌套在外层的try语句中。如果出现的异常在内层的try语句中没有被捕获， 则会被传递到外层try语句。

嵌 套的try语句执行时，每当遇到一个try语句，就会将异常的上下文信息压入堆栈，如果内层try没有捕获某一出现的异常，堆栈就会弹出该try语句，检 查下一条try语句的catch语句，知道检查完所有try语句，如果没有匹配的catch语句，虚拟机会处理该异常。

5.2 带资源的try语句

这里的资源 （resource）是指程序使用完后必须关闭的对象。更具体地，资源是指实现了java.lang.AntoCloseable接口的类的对象。因为 java.io.Closeable接口继承自AutoCloseable接口，所以实现了Closeable接口的类的对象都可以作为资源。 AutoCloseable接口中的close（）方法抛出Exception类型的异常，而Closeable（）接口的抛出的是 IOException类型，因此更加具体。try-with-resource确保使用的资源在try语句的结尾总会被关闭。其一般结构如下：

try（resource-specification） {

  //use the resouce }

其中，resource-specification用来声明和初始化资源。例如，

 

static String readFirstLineFromFile(String path) throws IOException {
    try (BufferedReader br =
                   new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
}

声 明和初始化了一个资源br，这个变量默认为final，也就是无法对其修改，不能赋给它新的值。使用带资源的try语句之后，不管try语句是正常结束还 是出现异常而结束，br都会被关闭。如果带有catch和finally语句，将在catch和finally语句执行之前关闭文件。在Java 7以前，上面代码可能修改为下面这样的：

 

static String readFirstLineFromFileWithFinallyBlock(String path)
                                                     throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
        return br.readLine();
    } finally {
        if (br != null) br.close();
    }
}

在 上面的代码中，如果readLine（）和close（）方法都抛出异常，那么readFirst...FinallyBlock()方法将会抛出来自 close（）方法的异常。相反地，在第一个例子中使用try-with-resource，如果try block（readLine）和try语句（不太明确？）同时抛出异常，那么来自readLine（）方法的异常将会被 ReadFirst...File抛出，来自try-with-resource的异常将会被挂起。这个挂起的异常在Java7以后可以被提取（通过 Throwable定义的getSuppressed（）方法）。

可以声明一个或者多个资源，中间用分号；隔开，如下例子：

 

try (
        java.util.zip.ZipFile zf =
             new java.util.zip.ZipFile(zipFileName);
        java.io.BufferedWriter writer =
            java.nio.file.Files.newBufferedWriter(outputFilePath, charset)
    ) {...}

try block结束之后，这两个资源都会被关闭，被关闭的顺序与它们创建时候的顺序相反，即先关闭writer，再关闭zf。如果在try block中抛出异常，并且在try-with-resouce 语句中也抛出两个异常（调用close（）方法时），那么try block的异常会被抛出，而带资源的try语句抛出的异常被挂起，我们可以通过调用try block抛出的异常对象的getSupressed（）方法获得这两个挂起的异常，这个方法返回一个Throwable数组，代表被挂起的异常。

 

5.3 异常挂起

// todo

6. 创建自己的异常类、throw抛出

如果想要创建自己的异常 类型，只需要定义Exception的子类，并且不需要事先任何内容即可作为异常。由于Exception继承了Throwable类，所以可以直接继承 或者重写Throwable中的类的方法，例如toString（）、getMessage（）、printStackTrace（）等等。默认的 toString方法显示异常的名称，然后冒号，然后是我们提供描述异常的信息。可以重写该方法以适应自己的要求。定义好自己的异常类后，可以将其应用到 catch语句中的参数，使用throw关键字抛出异常对象，格式为：

throw ThrowableInstance；

例如，创建了一个自定义异常类叫MyException，那么可以如下抛出异常：

throw new MyException("exception message");

异常抛出后，执行流会立即停止，寻找匹配的catch语句。

另外，也可以在catch语句中捕获异常之后，做些基本工作，比如输出日志等，然后再次将其抛出。如：

catch（NullPointerException e） {

    Log.log("null pointer...") // do what you want

    throw e; // rethrow

}

7. 链式异常

在程序中，我们常常用抛出另一个异常来作为异常处理，上面提到重新抛出异常的情况，我们甚至可以重新创建一个异常对象然后将其抛出。可以认为是第一个异常导致了第二个异常的产生，称为链式异常。Throwable类为链式异常提供了一些方法支持，如下：

public Throwable initCause(Throwable cause)；指定这个异常对象的背后异常，并返回该异常的引用。如果已经通过构造函数为异常指定引发异常（看接下去最后两个方法），就不能再使用initCause（）方法。

public Throwable getCause()； 返回异常的背后异常。如果背后不存在或者不知道，返回null。

public Throwable(Throwable cause)；在创建一个异常对象的时候就指定它的背后异常。

public Throwable(String message, Throwable cause)；跟上一个构造器一致，不过多加了描述信息。

下面是一个链式异常的例子：

 

try {

} catch (IOException e) {
    throw new SampleException("Other IOException", e);//maybe do something first
}

catch 语句捕获一个异常e后，将其作为另一个异常的背后异常（引发异常），然后抛出另一个新的异常。获取一个异常对象之后，还可以进行很多操作，可以使用预定义 的printStackTrace（）方法，但是如果我们想获得更加详细、更加符合我们要求的栈踪迹，可以获取更高栈踪迹信息，例如下面的代码：

 

catch (Exception cause) {
    StackTraceElement elements[] = cause.getStackTrace();
    for (int i = 0, n = elements.length; i < n; i++) {
        System.err.println(elements[i].getFileName()
            + ":" + elements[i].getLineNumber()
            + ">> "
            + elements[i].getMethodName() + "()");
    }
}

调用异常对象的getStackTrace（）方法，得到StackTraceElement数组，进而提取更多信息。下面的代码在异常发生时候使用java.util.logging包输出日志信息：

 

try {
    Handler handler = new FileHandler("OutFile.log");
    Logger.getLogger("").addHandler(handler);

} catch (IOException e) {
    Logger logger = Logger.getLogger("package.name");
    StackTraceElement elements[] = e.getStackTrace();
    for (int i = 0, n = elements.length; i < n; i++) {
        logger.log(Level.WARNING, elements[i].getMethodName());
    }
}

链式异常支持所需要的任意深度。

 

8.使用throws处理checked异常

8.1 throws

如果方法可能引发自身不进行处理的异常，就必须指明这一行为，以便方法的调用者能够保卫他们自己防备方法导致的异常。（你不干可以，得告诉别人）。通过在方法声明中使用throws来指明这一点。格式如下：

type mathod-name (parameter-list) throws exception-list {  ...  }

exception- list是可能抛出的异常类型，之间使用逗号隔开。对于checked 类型的异常，如果不在方法中捕获处理异常，也不在方法声明中用throws指明可能抛出的异常，则不能通过编译。在Eclipse中，如果没有对 checked异常进行，那么会提示你有2种方法可以解决，一种是try语句，另一种就是在方法声明中throws。正式一点的说法，Java的代码必须 符合“Catch or Specify Requirement.”，要么catch，要么Specify。Catch就是使用try语句捕获并处理异常。Specify就是在方法声明中使用throws指明它可能出现的异常类型。不符合“catch or specify”要求的代码无法通过编译。

8.2 throw and throws

这两个关键字经常容易混 淆，有必要区别一下。首先从形式（这两个关键词可以出现在代码什么地方）上看，throw可以出现在方法或者代码块当中（比如静态初始化块）。而 throws只出现在方法的声明中，紧跟方法参数列表之后，在接口中声明方法的时候，必须加上需要的throws。throw一次只能抛出一个异常对象，而throws可以指明该方法可能抛出的多个异常类型，使用逗号分隔。

从作用上看，throw 是创建异常对象，然后将其抛出，它后面跟的是对象！，完成的是“throw”操作。而throws只是声明方法可能抛出的异常，它后面紧跟着是异常类型 （type），完成的是“declare、specify”操作，具体的“抛出”动作由throw来完成。在Java中，把throws这一操作称为 “specify”，也就是指明、声明的意思。它是用于高速方法的调用者，这个方法可能会抛出哪些异常，使得方法调用者能够（也必须）做适当的异常处理， 尤其是checked异常。

可 以这么理解，如果把方法当做一个整体的话，throws在方法声明中指明该方法可能出现但是在内部又没有处理的异常（handler），指明的是异常类 型。throws作为方法的“发言人”告知外界可能出现的异常类型。而至于它内部是否抛出，如何抛出，是在本类方法中抛出还是在子类方法中抛出，外界一概 不知。甚至在方法内部抛出但是方法自己偷偷处理掉而不向外公开也是完全可以的。而完全具体的抛出动作，即创建异常对象并提交给运行时系统这一工作，则由默 默无闻的throw来完成。throw在自己的世界里创建、抛出异常对象，自己能处理（想处理、愿意处理）就自己处理，是在不愿意趟浑水，则告诉方法声明 让它告诉外界，让外界（方法调用者）自己去处理吧！

throw可以作为控制权转移的另一种方式（其他方式有return、continue、break），throw也可以用于退出switch中的case。例如：

 

int number = 5;
switch(number){
            case 1:
                throw new RuntimeException("Exception number 1");
            case 2:
                throw new RuntimeException("Exception number 2");
        }

另外，以try方式处理异常时，只能捕获在try block中可能抛出的异常。但是对于throws，可以抛出方法中不会出现的异常。之所以这么设计，是为了在子类的方法重写时允许抛出父类方法不会抛出的异常。[接下来这一段提到的异常都是特质checked异常]在 继承中，子类重写（覆盖）方法时不能抛出父类方法没有抛出的异常，这里的抛出是指throws抛出，在子类方法内部抛出父类方法没有抛出的异常并且方法自 己处理掉是可以的。原因在于，如果子类重写的方法throws父类方法没有throws的异常，当一个父类变量引用子类的对象的时候，调用这个重写的方法 时，编译器检查的时候，会要求我们处理父类中抛出的异常，而不会强制要求我们处理子类中的异常，但是实际调用方法的时候，可能会抛出没有处理的异常，这是 不允许的。而相反的，父类方法则可以抛出子类方法没有抛出的异常。这是“子类不能约束（restrict）父类”这一原则的一个例子。一个出现在父类方法 的异常说明（throws）的异常类型，不一定会出现在子类的throws中。极端情况是我覆盖父类方法的时候，把方法体设为空，什么也不干，什么异常也 不声明（throws）。不能基于throws来重载方法。值得注意的时，子类的构造器可以抛出任何类型的异常而不受父类的构造器限制，但是基本子类构造器throws语句必须包含父类throws语句中的所有checked异常类型！也就是说，对于非构造方法，声明抛出的checked异常类型只能减少不能增多，而对于构造器，checked异常类型的声明则只能多不能减少。而如果在不同的构造器中抛出不同类型的异常，如果在子类构造器中交叉调用了其他重载的父类构造器，也要throws相应的checked 异常。最后在强调一遍，这一段中说的异常类型都是指checked异常类型。这些规则对于unchecked异常不适用。

9. 静态块与异常：

9.1 初始化块处理异常

假设我们现在我这么一个类：

 

public class MyClass {
    private Random rand = new java.util.Random();
    private MegaString ms =
        new MegaString("Hello " + rand.nextInt(100));
    private int x = rand.nextInt(100);
    . . .
}

很 显然，每当一个MyClass对象创建的时候，都会执行类MegaString的构造方法从而创建一个MegaString对象。如果 MegaString没有使用throws抛出异常（也就是不会将异常传递到方法的调用者），那么一切安好。可是如果构造器throws异常呢，比如下面 这样：

 

class MegaString{
    public MegaString(String s) throws Exception {
        . . .
    }
}

那 么MyClass的编译将无法通过，因为创建MegaString对象的时候可能会抛出checked异常，而异常没有被处理。如果我们把 MegaClass的构造器抛出的是Error或者RuntimeException或者它们的子类，那么编译可以正常通过，因为java不强制要求除以 unckecked异常。

好了，假设构造器跑出了checked异常，那么怎么办？我们不允许将域的声明放到try语句中，一个解决办法就是将域的声明语句放进初始化块，如下所示：

 

      {
try {
    MegaClass mg = new MegaClass();
} catch (Exception e) {

}

这 样就能正常编译。如果你在Eclipse中开发，并且没有在静态块中处理异常，你会发现Eclipse提示是这样的：Default constructor cannot handle exception type Exception thrown by implicit super constructor. Must define an explicit constructor。它说默认的构造器不能处理异常，必须显式定义构造器。也就是提醒我们，异常可以在构造器中进行处理（域的初始化工作本质上是在构 造器中完成的？），是不是这样呢？假如我们为MyClass显式添加构造器，修改成下面这样：

 

public class MyClass {
    private Random rand = new java.util.Random();
    private MegaClass ms = new MegaClass("Hello " + rand.nextInt(100));
    private int x = rand.nextInt(100);

    public MyClass() throws Exception {

    }

}

那么这个类时可以通过编译。但是如果我想在处理异常而不是简单地将其throws呢？可以将初始化工作放在构造器中，如下：

 

public class MyClass {
    private Random rand = new java.util.Random();
    private MegaClass ms;
    private int x = rand.nextInt(100);

    public MyClass() {

        try {
            ms = new MegaClass("Hello " + rand.nextInt(100));
        } catch (Exception e) {

        }

    }

}

这 样便可以对异常进行更复杂的处理。可是问题又来了，如果我们有多个构造器，那么我们必须在每个构造器中都进行异常处理，所以有没有什么办法可以把异常处理 模块独立出来进而实现代码复用呢？有，就是我们前面用到的初始化块。每次创建一个对象（即调用构造函数时），初始化块都会被执行，可以粗略地理解为“相当 于把静态块嵌入到每个构造器”，因此，代码复用完美实现。当创建对象的时候，初始化和初始化块按照它在代码中的顺序执行，比如在下面的例子：

 

public class MyClass {
    private java.util.Random rand = new java.util.Random();
    private MegaString ms = null;
    {
        try { ms = new MegaString("Hello " + rand.nextInt(100)）; }
        catch (Exception e) { . . . }
    }
    private int x = rand.nextInt(100);
    . . .
}

初始化工作顺序如下：创建一个Random对象，赋给第一个域rand--->随机生成器获得第一个随机数，用于创建ms对象。--->随机生成器生成第二个随机数，赋给域x。

9.2 静态初始化块

如果我们把上面的域ms改成静态的，如下所示：

 

public class MyClass {
    private static MegaString sms = new MegaString("Goodbye");
    //. . .
}

编 译一样无法通过，而且也不能在构造器中处理异常了，因为这个域是静态的。当这个类被加载到虚拟机的时候，MegaString的构造器就会被调用用于创建 新的实例，异常将被抛出，而此时根本没有MyClass类的对象存在，也就不可能在构造器中处理异常了。如果采用静态块呢，如下：

 

public class MyClass {
    private Random rand = new java.util.Random();
    private static MegaClass ms;
    private int x = rand.nextInt(100);

    {
        try {
            ms = new MegaClass("Hello " + rand.nextInt(100));
        } catch (Exception e) {

        }

    }

}

这个类时可以编译通过的。那么此时是怎么回事，载入MyClass的时候，静态域ms会被初始化为null。然后当一旦有MyClass的对象被创建，这个静态域就会被新的值覆盖。我们加入一些代码看看结果：

 

public class MyClass {
    private Random rand = new java.util.Random();
    private static MegaClass ms;
    private int x = rand.nextInt(100);

    {
        try {
            ms = new MegaClass("Hello " + rand.nextInt(100));
        } catch (Exception e) {

        }

    }

    public static void main(String... args) {
        System.out.println("None object exist:" + MyClass.ms); //null
        new MyClass();
        System.out.println("1 object:" +  MyClass.ms.hashCode());
        new MyClass();
        System.out.println("2 objects:" +  MyClass.ms.hashCode());
    }

}

运行上面程序的输出结果如下：

 

None object exist:null
1 object:19157736
2 objects:29310343

首 先在创建任何对象之前输出静态域，此时可以看到ms为null。这就是载入MyClass类的时候进行的静态域初始化工作。创建一个对象之后，你会发现此 时的ms不再是null，它是一个对象了，我们输出它的哈希码。然后再创建另一个对象，再输出ms，哈希码变了，也就是说跟之前的对象已经不是同一个对象 了。因为创建第二个对象的时候，也执行了一遍初始化块代码，ms域被新值覆盖。这也许不是我们想要的结果，如果我们想让静态域只被初始化一次然后值保持不 变呢。这时候静态初始化块闪亮登场。我们把代码稍作修改，如下：

 

/**
 * @author Brandon B. Lin
 *
 */

public class MyClass {
    private static Random rand = new java.util.Random();
    private static MegaClass ms;
    private int x = rand.nextInt(100);

    static {
        try {
            ms = new MegaClass("Hello " + rand.nextInt(100));
        } catch (Exception e) {

        }

    }

    public static void main(String... args) {
        System.out.println(MyClass.ms == null); // null
        System.out.println("None object exist:" + MyClass.ms.hashCode());
        new MyClass();
        System.out.println("1 object:" + MyClass.ms.hashCode());
        new MyClass();
        System.out.println("2 objects:" + MyClass.ms.hashCode());
    }

}

注意几个地方的修改，首先rand被改为static，因为要在静态初始化块中调用。然后在初始化块之前加个static，在输出形式上我们也稍作修改，运行输出结果如下：

 

false
None object exist:19157736
1 object:19157736
2 objects:19157736

可以看到，即使没有实例被创建，域ms也不是null。而且往后无论多少对象被创建，也不会改变ms，输出结果中哈希码完全一样的。也就是说，静态初始化 块跟静态域一样，是在类被载入虚拟机的时候执行一次初始化工作，而在创建对象的时候，不会执行静态初始化块。当类被载入时，静态元素的执行顺序也是按照他 们出现的顺序进行，首先创建静态域rand，然后将ms初始化为null，然后执行静态初始化块，可以在静态初始化块的最开始（try语句之前）加入一行 代码：System.out.println("before static initializer: " + MyClass.ms); 此时输出结果如下：

 

before static initializer: null
false
None object exist:29310343
1 object:29310343
2 objects:29310343

可以看到静态初始化块之前，ms为null。

 

需要注意的一点是，初始化块（包括静态初始化块）必须正常退出（complete normally），比如我们在初始化块的最后一行加上一个throw语句，则无法通过编译。

 

10. Throwable及相关类研究：

10.1 Throwable简介

首先Throwable是个类，而不是接口，虽然它的命名看起来很像接口。Throwable是Java中所有异常类型的超类，用于表示程序中出现的某个异常，提供一些使用方法，以便追踪异常情况。两个直接子类是Error和Exception。

10.2 Throwable构造方法：

异 常可以由虚拟机抛出，也可以我们使用throw关键字抛出，抛出的异常类型都必须是Throwable的子类。为了创建一个异常对象，可以直接使用 Throwable类进行实例化。Throwable提供四个构造函数，其中的两个指定异常的背后异常（引发异常），而另外2个则没有。如下：

 

public Throwable(String message,  Throwable cause)

第一个参数是描述异常的信息（detailed message），可以在异常抛出后通过getMessage（）方法获得。第二个参数指定链式异常中的背后异常，也就是导致该异常对象产生的异常。如果在实例化的时候不指定背后异常，则变成如下构造器：

 

public Throwable(String message)

如果创建的时候没有指定背后异常，可以后面追加背后异常，调用Throwable类的initCasuse(Throwable)方法。也可以指定背后异常而不指定细节信息，得到下面的形式：

 

public Throwable(Throwable cause)

如果背后异常和细节信息都不想指定，也没有问题：

 

public Throwable()

简单明了，什么都没有。有些人可能什么都想要了，要把异常搞得复杂一点，没问题：

 

protected Throwable(String message,
                    Throwable cause,
                    boolean enableSuppression,
                    boolean writableStackTrace)

message/cause 两个参数跟前面介绍的完全一样。enableSuppression用于设置能否挂起异常，主要在带资源的try语句中应用，具体的在下面的方法介绍。 writableStackTrace设置能否写入堆栈，堆栈在异常发生的时候追踪方法列表等其他信息，具体下文相关方法介绍。

10.3 设置和获取背后异常：

如果在创建对象的时候没有使用cause参数指定背后异常，创建（由虚拟机或者代码）之后依然可以设置背后异常。使用initCause方法：

 

public Throwable initCause(Throwable cause)

这个方法最多只能被调用一次，将背后异常与当前异常关联起来，一般在构造器中调用或者在创建异常对象之后马上调用。它返回关联之后的当前异常（原来没有cause，调用该方法之后有了）。

如果出现下面其中一种情况，那么这个方法将抛出IllegalStateException异常：

1）如果创建该对象的时候已经指定背后异常，并且之前还没有调用过该方法；

2）创建对象的时候没有指定异常，但是已经调用过一次该方法。

也就是说，如果创建异常对象的时候指定了背后异常，那么这个方法一次不能调用。如果没有指定背后异常，最多只能调用一次（可以一次都不调用），否则将抛出IllegalStateException

如果将异常本身作为背后异常，那么将出现IllegalArgumentException异常。异常本身不能作为自己的背后异常。

可以设置背后异常，也就有相应获取异常的方法getCuase（）

 

public Throwable getCause()

如果该异常没有指定背后异常，也就是创建对象的时候没有指定背后异常，创建之后也没用调用initCause指定背后异常，那么将返回null。

如果背后异常存在，返回背后异常，这个背后异常可能是创建的时候指定的，也可能是创建之后再指定的。需要注意的是，返回null并不一定就代表背后异常不存在，可能背后异常存在但是不知道（unknown）。

10.4 有关堆栈踪迹的方法：

栈踪迹用于记录方法调用关系等其他信息，对于处理异常十分关键。Throwable类定义了好几个相关的方法：

 

public Throwable fillInStackTrace()

这个方法写入与该异常对象相关的栈踪迹，具体指当前线程的栈帧（stack frame）。如果在创建对象的时候将writableStackTrace参数设置为false，则该方法不执行什么操作，对栈踪迹没有影响。返回的是 对当前异常的引用。我们来看看具体的一个例子：

/**
 * @author Brandon B. Lin
 *
 */
public class Rethrow {

    public static void f() throws Exception {
        System.out.println("方法f()抛出异常");
        throw new Exception("我是来自f()的异常");
    }

    public static void g() throws Exception {
        try {
            f();
        } catch (Exception e) {
            System.out.println("方法g()中輸出的堆棧信息");
            for(StackTraceElement s:e.getStackTrace()) {
                System.out.println(s.getMethodName());
            }
            throw e;
        }
    }

    public static void h() throws Exception {
        try {
            f();
        } catch (Exception e) {
            System.out.println("方法h()中輸出的堆棧信息");
            for(StackTraceElement s:e.getStackTrace()) {
                System.out.println(s.getMethodName());
            }
            throw (Exception)e.fillInStackTrace();
        }
    }

    /**
     * @param args
     */
    public static void main(String[] args) {
        try {
            g();
        } catch(Exception e) {
            System.out.println("方法main()中輸出的堆棧信息");
            for(StackTraceElement s:e.getStackTrace()) {
                System.out.println(s.getMethodName());
            }
        }

        try {
            h();
        } catch(Exception e) {
            System.out.println("方法main()中輸出的堆棧信息");
            for(StackTraceElement s:e.getStackTrace()) {
                System.out.println(s.getMethodName());
            }
        }

    }

}

首 先定义一个抛出Exception异常的方法f（），然后分别在g（）和h（）方法中调用f（）方法，唯一的区别就是在g（）方法中，只是简单地把异常对 象重新抛出。但是在h（）方法中，调用了异常对象的fillInStackTrace()方法，使得异常对象的对栈踪迹发生变化。然后在main方法中分 别调用g和h，并且在方法中打印异常的堆栈踪迹，即调用的方法列表，然后把main方法中的输出和g和h方法中的输出做比较，最后输出结果如下（添加了分 隔线）：

方法f()抛出异常
方法g()中輸出的堆棧信息
f
g
main
===================
方法main()中輸出的堆棧信息
f
g
main
===================
方法f()抛出异常
方法h()中輸出的堆棧信息
f
h
main
===================
方法main()中輸出的堆棧信息
h
main

比较可以看到，在没有调用fillInStackTrace（）方法重写堆栈踪迹的情况下，f（）方法和main（）输出的堆栈踪迹是一样的。

而如果调用了这个方法重写堆栈踪迹，则调用fillInStackTrace方法的这一行成为了异常新的堆栈踪迹起点，有关原来异常发生点的信息全 部丢失，所以输出方法列表的时候只输出h和main。因此，把握好异常抛出点很重要，是简单地将原来异常对象抛出，还是调用 fillInStackTrace方法覆盖堆栈，还是抛出一个全新的异常对象，其堆栈踪迹都不一样。

 

如果想获取堆栈踪迹的信息，调用下面的方法：

 

public StackTraceElement[] getStackTrace()

该 方法返回对栈踪迹的数组。每个对栈踪迹代表一个堆栈帧，即对应一个方法调用，与出现异常之前调用的最后一个方法相关堆栈踪迹存在该数组的第一个元素，第一 个元素对应的方法，通常都是创建和抛出异常对象的方法。通过调用StackTraceElement的方法，可以获取每个堆栈踪迹相关的信息，例如方法名 称。对获取的数组进行赋值重写，不会影响该方法的后续调用，也就是该方法返回的只是一个副本。

 

public void setStackTrace(StackTraceElement[] stackTrace)

设 置堆栈踪迹，一般用于特殊的程序（RPC Framework），允许对默认的堆栈踪迹（调用fillInStackTrace（）方法时写入）进行重写。调用getStackTrace或者 PrintStackTrace时将使用这里设置的对栈踪迹。如果传入的参数为null，或者参数中的某一数组元素为null，抛出 NullPointerException异常。处理异常时，我们经常输出堆栈踪迹，使用的是下面的方法：

 

public void printStackTrace()
public void printStackTrace(PrintStream s)
public void printStackTrace(PrintWriter s）

将堆栈踪迹写入到指定的输出流中，如果没有指定参数，输出到标准错误流，即System.err。

10.5 挂起异常：

在带资源的try语句中，我们简单提到了异常挂起。下面我们深入地看一下：

在 常规的try语句try { ... }中，虽然try block中可能抛出的异常有多个，但是在实际的运行中，只有一个异常对象会被抛出（因为一旦某个异常对象被抛出，try block中往后的语句就不会被执行）。但是在带资源的try语句：try（resouce1：resource2）{ ... }中，编译器对这个try语句生成了隐式的finally，并且这个用于关闭资源的finally会在catch和显示的finally执行之前执行，因 此从整体上看，try可能会抛出多个异常，因此必须做出选择，此时编译器选择将try-with-resouce-statement（也就是隐式的、在 catch之前执行的、finally语句）中抛出的异常挂起（suppressed，或者成为沪市ignore），而将try block中的异常抛出。于是出现了挂起异常这个概念。

 

public final void addSuppressed(Throwable exception)

上面的这个方法就是将try-with-resource statement抛出的异常挂起，指定给try block抛出的异常，这个方法通常被try-with-resource statement自动、隐式地调用，例如看看前面的一个例子：

static String readFirstLineFromFile(String path) throws IOException {
    try (BufferedReader br =
                   new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
}

例子中的带资源的try语句在关闭br的时候可能会产生异常，记为ex1. try block中的readLine（）也可能产生异常，记为ex2. 编译器通过调用ex2.addSuppressed(ex1)将带资源的try语句抛出的异常挂起，而将ex2抛出。

传统的try语句可能会这么处理：

 

static String readFirstLineFromFileWithFinallyBlock(String path)
                                                     throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
        return br.readLine();
    } finally {
        if (br != null) br.close();
    }
}

这种情况下编译器将try block中产生的异常捕获（不会挂起），而将finally产生的异常抛出。为了验证这一点，我们设计一个这样的类：

/**
 * @author Brandon B. Lin
 *
 */
public class DirtyResource implements AutoCloseable {

    /**
     * access resouce
     *
     * @throws RuntimeException
     *             no matter how you call this method
     */
    public void accessResource() {
        throw new RuntimeException("runtime exception from accessResource()");
    }

    /**
     *
     * @throws Exception
     */
    @Override
    public void close() throws Exception {
        throw new NullPointerException("I am nullpointer Exception from close()");
    }

}

然后以传统的try语句使用这个类：

public class Test1 {

    /**
     * @param args
     */
    public static void main(String[] args) {
        try {
            memberFunction();
        } catch (Exception ex) {
            System.err.println("Exception encountered: " + ex.toString());
            final Throwable[] suppressed = ex.getSuppressed();
            if (suppressed.length > 0) {
                System.err.println("There are " + suppressed.length
                        + "suppressed exception");
                for (Throwable throwable : suppressed) {
                    System.err.println(throwable.toString());
                }
            }
        }

    }

    private static void memberFunction() throws Exception {
        DirtyResource resource = new DirtyResource();
        try {
            resource.accessResource();
        } finally {
            resource.close();
        }
    }

}

输出结果为：

Exception encountered: java.lang.NullPointerException: I am nullpointer Exception from close()

可以看到，抛出的是来自close（）方法的异常，而来自accessResource方法的异常没有抛出，也没有挂起，只是把它“丢失”。现在修改一下代码，将来自accessresource方法的异常挂起：

/**
 * @author Brandon B. Lin
 *
 */
public class Test2 {

    /**
     * @param args
     */
    public static void main(String[] args) {
        try {
            memberFunction();
        } catch (Exception ex) {
            System.err.println("Exception encountered: " + ex.toString());
            final Throwable[] suppressed = ex.getSuppressed();
            if (suppressed.length > 0) {
                System.err.println("There are " + suppressed.length
                        + " suppressed exception");
                for (Throwable throwable : suppressed) {
                    System.err.println(throwable.toString());
                }
            }
        }

    }

    private static void memberFunction() throws Exception {
        Throwable th = null;
        DirtyResource resource = new DirtyResource();
        try {
            resource.accessResource();
        } catch (Exception ex) {
            th = ex;
        } finally {
            try {
                resource.close();
            } catch (Exception e) {
                if (th != null) {
                    e.addSuppressed(th);
                    throw e;
                }
            }

        }

    }
}

输出为：

Exception encountered: java.lang.NullPointerException: I am nullpointer Exception from close()
There are 1 suppressed exception
java.lang.RuntimeException: runtime exception from accessResource()

我们最后使用带资源的try语句来操作一下：

/**
 * @author Brandon B. Lin
 *
 */
public class Test3 {

    /**
     * @param args
     */
    public static void main(String[] args) {
        try {
            memberFunction();
        } catch (Exception ex) {
            System.err.println("Exception encountered: " + ex.toString());
            final Throwable[] suppressed = ex.getSuppressed();
            if (suppressed.length > 0) {
                System.err.println("There are " + suppressed.length
                        + " suppressed exception");
                for (Throwable throwable : suppressed) {
                    System.err.println(throwable.toString());
                }
            }
        }

    }

    private static void memberFunction() throws Exception {
        try (DirtyResource d = new DirtyResource()) {
            d.accessResource();
        }
    }
}

此时我们没有手动将来自accessResource方法的异常挂起，但是调用getSuppressed方法的时候，依然能得到挂起异常，说明编译器已经自动、隐式地帮我们把异常挂起了。

输出为：

 

Exception encountered: java.lang.RuntimeException: runtime exception from accessResource()
There are 1 suppressed exception
java.lang.NullPointerException: I am nullpointer Exception from close()

以上例子参考：http://howtodoinjava.com/2013/03/13/suppressed-exceptions-in-java-7/

添加完挂起异常（通常是隐式、自动的，也可以手动添加挂起异常）之后，就可以调用getSuppressed方法获取这些挂起异常：

 

public final Throwable[] getSuppressed()

返回的是一个代码挂起异常列表的Throwable数组。如果创建异常对象时将enableSuppression设为false或者没有异常被挂起，将返回空数组而不是null。

10.6 其他方法：

除了上面介绍的，还有用于提取细节信息的方法、toString方法。

 

public String getMessage()
public String getLocalizedMessage()
public String toString()

对于toString，Throwable提供了默认的实现方式，输出格式为：     异常对象的类型：细节信息   可以重写该方法获取你想要的输出格式。

11.assert：断言

Java1.4 加入了断言的概念，它是用于测试某种假设（presumed）的、推测的状态（state）是否确实存在。

|| 如果状态跟假设的不符，那么会抛出AssertionError。

|| 断言不是用于测试可以预期的值。

断言基本格式如下：

assert（condition）[: messageExpression]

其中方括号部分可以省略，这个消息将会传递给AssertError的构造器。还是非常抽象难懂，举个例子，我们使用一个第三方类库中的方法，该方法声明它将返回一个0-1之间的double值，但是我们想确认是否的确如此（断言）！代码如下：

 

public class AssertionTest {

  public static void main(String[] args) {
    double value = thirdPartyFunction();
    assert (value >= 0 && value < 1) :
       " thirdPartyFunction value " + value + " out of range";
    System.out.println("Value is " + value);
  }

  public static double thirdPartyFunction() {
    return 5.0;
  }
}

如果断言的条件为false，也就是方法返回的值不在0-1之间，那么将抛出AssertError。

断言用于代码调试，在正式产品中一般将会关闭。想要运行含有断言的版本，使用java -ea ClassName开启 或者用-enableassertion，关闭使用参数-da。注意断言不能对程序的正常运行产生副作用。

12. 常见的预定义异常

Java库中定义了许多异常类型，下面简要介绍一些。

12.1 RuntimeException子类

（在java.lang中定义的、unchecked）

》ArithmeticException：算数错误，例如除数为0.

》ArrayIndexOutofBoundsException：数组索引越界。（编译期间不会检查是否越界）

》StringIndexOutOfBoundsException：超出字符串边界

》IndexOutOfBoundsException：某些类型索引越界，例如数组、String索引、Vector索引。ArrayIndexOutOfBoundsException是它的子类。

》ArrayStoreException：使用不兼容的类型为数组袁术赋值，例如：

Object[] strings = new String[3]; string[1] = new Integer(1);

》ClassCastException：无效的类型转换，例如：

Object o = new String("TT");   System.out.println((Integer)o);

》EnumConstantNotPresentException：试图使用用定义的枚举值

》IllegalArgumentException：使用非法调用参数。

》NegativeArraySizeException：使用负数创建数组

》NullPointerException：非法使用空引用

》UnsupportedOperationException：遇到不支持的操作

》NumberFormatException：字符串到数值格式的无效转换

12.2 java.lang中定义的checked异常：

》ClassNotFoundException：类未找到

》CloneNotSupportedException：试图克隆没有实现Cloneable接口的对象

》InterruptedException：一个线程被另一个线程中断

》InstantiationException：试图为抽象类或者接口创建对象

》NoSuchFieldException：请求的域不存在

》NoSuchMethodException：请求的方法不存在。

----------------------------------------------------------

后记：几经修改，总算完成了一个比较完整的版本，虽然对于Java的异常来说，也许这知识皮毛。但是至少对异常有个比较全面的认识。学习最重要的大概就是思考和总结吧，加油。

 

 

http://blog.csdn.net/bingduanlbd/article/details/27886093