Java 异常

概述

异常：程序运行时，发生的不被期望的事件，它阻止了程序按照程序员的预期正常执行，这就是异常。Java 提供了针对异常的解决办法 —— 异常处理机制。

• 异常处理机制能让程序在异常发生时，按照代码的预先设定的异常处理逻辑，针对性地处理异常，让程序尽最大可能恢复正常并继续执行，且保持代码的清晰
• Java中的异常可以是函数中的语句执行时引发的，也可以是程序员通过 throw 语句手动抛出的，只要在 Java 程序中产生了异常，就会用一个对应类型的异常对象来封装异常，JRE 就会试图寻找异常处理程序来处理异常
• Throwable类是Java异常类型的顶层父类，一个对象只有是 Throwable 类的（直接或者间接）实例，他才是一个异常对象，才能被异常处理机制识别。JDK 中内建了一些常用的异常类，我们也可以自定义异常

Java 异常分类

Java 异常的顶级父类：Throwable

Throwable 派生出 Error 类和 Exception 类：

• Error：错误，代表了 JVM 本身的错误，不能被程序员通过代码处理
• Exception：异常，代表了程序运行时的不被期望的事件，是 Java 异常处理的核心

Exception 又分为运行时异常（RuntimeException）和非运行时异常：

• 运行时异常，又叫非检查异常（unchecked exception），是 RuntimeException 及其子类异常，这些异常是不检查异常，程序中可以选择捕获处理该类异常，也可以不处理。这些异常一般由程序逻辑错误引起，程序应该从逻辑角度尽可能避免这类异常的发生。
• 非运行时异常，又叫检查异常（checked exception），是除 RuntimeException 及其子类异常之外的异常，javac 强制要求程序员为该类异常做预备处理工作，即使用 try … catch … finally … 对该类异常进行处理或使用 throws 子句进行抛出，否则编译不会通过

异常类结构图：

Java 中常见的运行时异常：

Java 中常见的非运行时异常：

Java 异常处理实践原则

1. 使用异常，而不是返回码（或类似），因为异常会更加的详细
2. 主动捕获检查性异常，并对异常信息进行反馈（日志或标记）
3. 保持代码整洁，一个方法中不要有多个 try … catch 或者嵌套的 try … catch
4. 捕获更加具体的异常，而不是通用的 Exception
5. 合理设计自定义的异常类

异常的抛出

异常是在执行某个函数时引发的，而函数又是层级调用形成调用栈的。因此，只要一个函数发生了异常，那么它的所有 caller 都会被异常影响。当这些被影响的函数以异常信息输出时，就形成了异常追踪栈。
异常最先发生的地方，叫作异常抛出点。

从上面的例子可以看出，当devide函数发生除0异常时，devide 函数将抛出ArithmeticException 异常，因此调用他的 CMDCalculate 函数也无法正常完成，因此也发送异常，而 CMDCalculate 的caller —— main 因为 CMDCalculate 抛出异常，也发生了异常，这样一直向调用栈的栈底回溯。这种行为叫做异常的冒泡，异常的冒泡是为了在当前发生异常的函数或者这个函数的caller中找到最近的异常处理程序。由于这个例子中没有使用任何异常处理机制，因此异常最终由main函数抛给JRE，导致程序终止。

异常的基本语法

在编写代码处理异常时，对于检查异常，有2种不同的处理方式：

1. 使用try…catch…finally语句块处理它
2. 在函数签名中使用 throws 声明交给函数调用者 caller 去解决

try…catch…finally 语句块：

try{
    //try块中放可能发生异常的代码。
    //如果执行完try且不发生异常，则接着去执行 finally 块和 finally 后面的代码（如果有的话）。
    //如果发生异常，则尝试去匹配 catch 块。
}catch(SQLException SQLexception){
    //每一个catch块用于捕获并处理一个特定的异常，或者这异常类型的子类。Java7中可以将多个异常声明在一个catch中。
    //catch后面的括号定义了异常类型和异常参数。如果异常与之匹配且是最先匹配到的，则虚拟机将使用这个catch块来处理异常。
    //在catch块中可以使用这个块的异常参数来获取异常的相关信息。异常参数是这个catch块中的局部变量，其它块不能访问。
    //如果当前try块中发生的异常在后续的所有catch中都没捕获到，则先去执行finally，然后到这个函数的外部caller中去匹配异常处理器。
    //如果try中没有发生异常，则所有的catch块将被忽略。
}catch(Exception exception){
    //...
}finally{
    //finally块通常是可选的。
    //无论异常是否发生，异常是否匹配被处理，finally都会执行。
    //一个try至少要有一个catch块，否则， 至少要有1个finally块。但是finally不是用来处理异常的，finally不会捕获异常。
    //finally主要做一些清理工作，如流的关闭，数据库连接的关闭等。 
}

注意事项：

1. try、catch、finally 三个代码块中的局部变量不能共享使用
2. 每一个 catch 块用于处理一个异常。异常匹配是按照 catch 块的顺序从上往下寻找的，只有第一个匹配的 catch 会得到执行。匹配时，不仅运行精确匹配，也支持父类匹配，因此，如果同一个 try 块下的多个 catch 异常类型有父子关系，应该将子类异常放在前面，父类异常放在后面，这样保证每个catch块都有存在的意义。
3. java中，异常处理的任务就是将执行控制流从异常发生的地方转移到能够处理这种异常的地方去。也就是说：当一个函数的某条语句发生异常时，这条语句的后面的语句不会再执行，它失去了焦点。执行流跳转到最近的匹配的异常处理 catch 代码块去执行，异常被处理完后，执行流会接着在“处理了这个异常的catch代码块”后面接着执行。

   • 有的编程语言当异常被处理后，控制流会恢复到异常抛出点接着执行，这种策略叫做：resumption model of exception handling（恢复式异常处理模式 ）
   • 而 Java 则是让执行流恢复到处理了异常的 catch 块后接着执行，这种策略叫做：termination model of exception handling（终结式异常处理模式）

try {
    System.out.println("异常点前的语句块");
    int a = 4/0;
    System.out.println("异常点后的语句块"); // 该语句无法访问
} catch (ArithmeticException e) {
    System.out.println("执行 catch 语句块！");
}
System.out.println("catch代码块后的语句");

1. finally 块不管异常是否发生，只要对应的 try 执行了，则 finally 块一定会执行。
2. try … catch … finally 中存在 return 语句时，存在如下情况：
   • finally 语句会在 try 语句的 return 语句之前执行
   • finally 语句中的 return 语句会覆盖 try 和 catch 中的 return 语句
   • try 和 catch 中的 return 语句根据是否发生异常能否到达有关

throws 函数声明：如果一个方法内部的代码会抛出检查异常（checked exception），而方法自己又没有完全处理掉，则 javac 保证你必须在方法的签名上使用 throws关键字声明这些可能抛出的异常，否则编译不通过。
采取 throws 异常处理的原因：方法本身不知道如何处理这样的异常，或者说让调用者处理更好，调用者需要为可能发生的异常负责。

throw 异常抛出语句：throw new Throwable()，显示抛出一个异常，与 JRE 自动形成的异常点没有区别。

自定义异常

• 自定义检查异常，继承 Exception 类
• 自定义运行时异常，继承 Runtime 类

自定义异常类包含的元素：

• 一个无参构造函数
• 一个带有 String 参数的构造函数，并传递给父类的构造函数
• 一个带有 String 参数和 Throwable 参数，并都传递给父类构造函数
• 一个带有 Throwable 参数的构造函数，并传递给父类的构造函数

IOException 源码示例：

public class IOException extends Exception {
    static final long serialVersionUID = 7818375828146090155L;
    /**
     * Constructs an {@code IOException} with {@code null}
     * as its error detail message.
     */
    public IOException() {
        super();
    }
    /**
     * Constructs an {@code IOException} with the specified detail message.
     *
     * @param message
     *        The detail message (which is saved for later retrieval
     *        by the {@link #getMessage()} method)
     */
    public IOException(String message) {
        super(message);
    }
    /**
     * Constructs an {@code IOException} with the specified detail message
     * and cause.
     *
     * <p> Note that the detail message associated with {@code cause} is
     * <i>not</i> automatically incorporated into this exception's detail
     * message.
     *
     * @param message
     *        The detail message (which is saved for later retrieval
     *        by the {@link #getMessage()} method)
     *
     * @param cause
     *        The cause (which is saved for later retrieval by the
     *        {@link #getCause()} method).  (A null value is permitted,
     *        and indicates that the cause is nonexistent or unknown.)
     *
     * @since 1.6
     */
    public IOException(String message, Throwable cause) {
        super(message, cause);
    }
    /**
     * Constructs an {@code IOException} with the specified cause and a
     * detail message of {@code (cause==null ? null : cause.toString())}
     * (which typically contains the class and detail message of {@code cause}).
     * This constructor is useful for IO exceptions that are little more
     * than wrappers for other throwables.
     *
     * @param cause
     *        The cause (which is saved for later retrieval by the
     *        {@link #getCause()} method).  (A null value is permitted,
     *        and indicates that the cause is nonexistent or unknown.)
     *
     * @since 1.6
     */
    public IOException(Throwable cause) {
        super(cause);
    }
}