09. Java 异常

最新推荐文章于 2024-07-16 16:14:54 发布

acc8226

最新推荐文章于 2024-07-16 16:14:54 发布

阅读量439

点赞数 3

分类专栏： Java 学习文章标签： java 开发语言

本文链接：https://blog.csdn.net/acc8226/article/details/137105373

版权

Java 学习专栏收录该内容

10 篇文章 0 订阅

订阅专栏

异常的层次

异常指的是程序运行时出现的不正常情况。程序运行过程中难免会发生异常，发生异常并不可怕，程序员应该考虑到有可能发生这些异常，编程时应能正确的处理异常，使成为健壮的程序。

异常是相对于 return 的一种退出机制，可以由系统触发，也可以由程序通过 throw 语句触发，异常可以通过 try/catch 语句进行捕获并处理，如果没有捕获，则会导致程序退出并输出异常栈信息。

Java 的异常类是处理运行时的特殊类，每一种异常对应一种特定的运行错误。所有 Java 异常类都是系统类库 Exception 类的子类。

异常类继承层次图

Throwable 类

所有的异常类都直接或间接地继承于 java.lang.Throwable 类，在 Throwable 类有几个非常重要的方法：

String getMessage()：获得发生异常的详细消息。
void printStackTrace()：打印异常堆栈跟踪信息。
void printStackTrace(PrintStream s) 通常用该方法将异常内容保存在日志文件中，以便查阅。
String toString()：获得获取异常类名和异常信息的描述。

public class Throwable implements Serializable {
    ...

    public String getMessage() {
        return detailMessage;
    }

    public void printStackTrace() {
        printStackTrace(System.err);
    }

    public void printStackTrace(PrintStream s) {
        printStackTrace(new WrappedPrintStream(s));
    }

    public String toString() {
        String s = getClass().getName();
        String message = getLocalizedMessage();
        return (message != null) ? (s + ": " + message) : s;
    }
    ...
}

Error 和 Exception 类

Throwable 有两个直接子类：Error 和 Exception。

Error 是程序无法恢复的严重错误，程序员根本无能为力，程序中不能对其编程处理，对 Error 一般不编写针对性的代码对其进行处理只能让程序终止。例如：JVM 内部错误、内存溢出和资源耗尽等严重情况。

Exception 是程序可以恢复的异常，它是程序员所能掌控的。例如：除零异常、空指针访问、网络连接中断和读取不存在的文件等。

Exception 类有若干子类，每个子类代表一种特定的运行错误,这些子类有的是系统事先定义好并包含在 Java 类库中的，成为系统定义的运行异常。

ArrayIndexOutOfBoundsException 数组越界访问
ArithmeticException 算术运算错误
ClassNotFoundException 未找到要装载的类
FileNotFoundException 文件找不到, checked 异常
InterruptedException 中断异常, 线程在进行暂停处理时(如睡眠)被调度打断将引发该异常
IOException 输入, 输出错误, checked 异常
NullPointerException 空指针异常, unchecked 异常

异常分类

已检异常 checked

在明确的特定情况下抛出，经常是应用能部分或完全恢复的情况。例如，某段代码要在多个可能的目录中寻找配置文件。如果试图打开的文件不在某个目录中，就会抛出 FileNotFoundException 异常。在这个例子中，我们想捕获这个异常，然后在文件可能出现的下一个位置继续尝试。也就是说，虽然文件不存在是异常状况，但可以从中恢复，这是意料之中的失败。

非受检异常 unchecked

在 Java 环境中有些失败是无法预料的，这些失败可能是由运行时条件或滥用库代码导致的。例如把无效的 null 传给使用对象或数组的方法，会抛出 NullPointerException 异常。基本上任何方法在任何时候都可能抛出未检异常。这是 Java 环境中的墨菲定律：“会出错的事总会出错。”从未检异常中恢复，虽说不是不可能，但往往很难，因为完全不可预知。运行时异常往往是程序员所犯错误导致的，健壮的程序不应该发生运行时异常。

异常的处理

涉及了五个关键字 try catch finally throw throws。

对待受检查异常。如果当前方法有能力解决，则捕获异常进行处理；没有能力解决，则抛出给上层调用方法处理。
try…catch…finally 或者 try-with-resources (Java7 增加) 语句结构进行捕获
try 必须带有 catch 或者 finally，两者至少二选一或者资源声明才可以使用。
一个 try 可以引导多个 catch 块。但是不要定义多余的 catch 块，多个 catch 块的异常出现继承关系，父类异常 catch 块放在最后面。
异常发生后，try 块中的剩余语句将不再执行。
catch 块中的代码要执行的条件是，首先在 try 块中发生了异常，其次异常的类型与 catch 要捕捉的一致。建议声明更为具体的异常，这样处理的可以更具体。当捕获的多个异常类之间存在父子关系时，捕获异常顺序与 catch 代码块的顺序有关。一般先捕获子类，后捕获父类，否则子类捕获不到。
可以无 finally 部分，但如果存在，则无论异常发生否，finally 部分的语句均要执行。即便是 try 或 catch 块中含有退出方法的语句 return，也不能阻止 finally 代码块的执行; 除非执行 System.exit(0) 等导致程序停止运行的语句。

try-catch 不仅可以嵌套在 try 代码块中，还可以嵌套在 catch 代码块或 finally 代码块，finally 代码块后面会详细介绍。try-catch 嵌套会使程序流程变的复杂，如果能用多 catch 捕获的异常，尽量不要使用 try catch 嵌套。特别对于初学者不要简单地使用 Eclipse 的语法提示不加区分地添加 try-catch 嵌套，要梳理好程序的流程再考虑 try-catch 嵌套的必要性。

传统处理

try {语句块;}
catch (异常类名   参变量名) {语句块;}
finally {语句块;} // 定义一定执行的代码:通常用于关闭资源

Java 7 推出了多重捕获（multi-catch）技术, 可以把这些异常合并处理

try {
    // 可能会发生异常的语句
} catch (IOException | ParseException e) {
    // 调用方法 methodA 处理
}

finally 代码块

try-catch 语句后面还可以跟有一个 finally 代码块，try-catch-finally 语句语法如下：

注意：为了代码简洁等目的，可能有的人会将 finally 代码中的多个嵌套的 try-catch 语句合并。每一个 close()方法对应关闭一个资源，如果某一个 close() 方法关闭时发生了异常，那么后面的也不会关闭，因此这种代码是有缺陷的。

释放资源

有时在 try-catch 语句中会占用一些非 Java 资源，如：打开文件、网络连接、打开数据库连接和使用数据结果集等，这些资源并非 Java 资源，不能通过 JVM 的垃圾收集器回收，需要程序员释放。为了确保这些资源能够被释放可以使用 finally 代码块或 Java 7 之后提供自动资源管理（Automatic Resource Management）技术。

自动资源管理

使用 finally 代码块释放资源会导致程序代码大量增加，一个 finally 代码块往往比正常执行的程序还要多。在Java 7之后提供自动资源管理（Automatic Resource Management）技术，可以替代 finally 代码块，优化代码结构，提高程序可读性。

自动资源管理是在 try 语句上的扩展，语法如下：

try (声明或初始化资源语句) {
    // 可能会生成异常语句
} catch(Throwable e1){
    // 处理异常 e1
} catch(Throwable e2){
    // 处理异常 e2
} catch(Throwable eN){
    // 处理异常 eN
}

在 try 语句后面添加一对小括号“()”，其中是声明或初始化资源语句，可以有多条语句语句之间用分号“;”分隔。

示例代码如下：

public class HelloWorld {
    public static void main(String[] args) {
        Date date = readDate();
        System.out.println("读取的日期  = " + date);
    }
    public static Date readDate() {
        // 自动资源管理
        try (FileInputStream readfile = new FileInputStream("readme.txt");
                InputStreamReader ir = new InputStreamReader(readfile);
                BufferedReader in = new BufferedReader(ir)) {

            // 读取文件中的一行数据
            String str = in.readLine();
            if (str == null) return null;
            DateFormat df = new SimpleDateFormat("yyyy-MM-dd");
            Date date = df.parse(str);
            return date;
        } catch (IOException e) {
            System.out.println("处理IOException...");
            e.printStackTrace();
        } catch (ParseException e) {
            System.out.println("处理ParseException...");
            e.printStackTrace();
        }
        return null;
    }
}

注意所有可以自动管理的资源需要实现 AutoCloseable 接口，上述代码中三个输入流 FileInputStream、InputStreamReader 和 BufferedReader 从 Java 7之后实现 AutoCloseable 接口，具体哪些资源实现 AutoCloseable 接口需要查询 API文档。

资源的声明和初始化放在 try 语句内，不用再调用 finally，在语句执行完 try语句后，会自动调用资源的 close() 方法。资源可以定义多个，以分号分隔。在 Java 9 之前，资源必须声明和初始化在 try 语句块内，Java 9去除了这个限制，资源可以在try语句外被声明和初始化，但必须是 final 的或者是事实上 final 的（即虽然没有声明为final但也没有被重新赋值）。

finally 语句有一个执行细节，如果在 try 或者 catch 语句内有 return 语句，则 return 语句在 finally 语句执行结束后才执行，但 finally 并不能改变返回值，我们来看下面的代码。

public static int yyy() {
    int ret = 1;
    try {
        return ret; // 输出结果为 1
    } finally {
        ret = 2;
    }
}

如果在 finally 中也有 return 语句呢？try 和 catch 内的 return 会丢失，实际会返回 finally 中的返回值。所以，一般而言，为避免混淆，应该避免在 finally 中使用 return 语句或者抛出异常，如果调用的其他代码可能抛出异常，则应该捕获异常并进行处理。

throws 与声明方法抛出异常

在一个方法中如果能够处理异常，则需要捕获并处理。但是本方法没有能力处理该异常，捕获它没有任何意义，则需要在方法后面声明抛出该异常，通知上层调用者该方法有可以发生异常。

注意：如果声明抛出的多个异常类之间有父子关系，可以只声明抛出父类。但如果没有父子关系情况下，最好明确声明抛出每一个异常，因为上层调用者会根据这些异常信息进行相应的处理。假如一个方法中有可能抛出 IOException 和 ParseException 两个异常，那么声明抛出 IOException 和 ParseException 呢？还是只声明抛出 Exception 呢？因为 Exception 是 IOException 和 ParseException 的父类，只声明抛出 Exception 从语法是允许的，但是声明抛出 IOException 和 ParseException 更好一些。

使用 throw 抛出异常。异常的本质是对象因为 throw 关键词后跟的是 new 运算符来创建的一个异常对象。
使用 throws 关键字抛出一个或多个异常。

自定义异常

有些公司为了提高代码的可重用性，自己开发了一些 Java 类库或框架，其中少不了自己编写了一些异常类。实现自定义异常类需要继承 Exception 类或其子类，如果自定义运行时异常类需继承 RuntimeException 类或其子类。

我们通过继承 Exception 或者 RuntimeException 来定义一个异常。

Java 内部定义 WebServiceException 示例：

package javax.xml.ws;

public class WebServiceException extends java.lang.RuntimeException {

  public WebServiceException() {
    super();
  }

  public WebServiceException(String message) {
    super(message);
  }

  public WebServiceException(String message, Throwable cause) {
    super(message,cause);
  }

  public WebServiceException(Throwable cause) {
    super(cause);
  }

}

和很多其他异常类一样，我们没有定义额外的属性和代码，只是继承了Exception，定义了构造方法并调用了父类的构造方法。

throw 与显式抛出异常

通过 throw 语句显式抛出异常, 显式抛出异常目的有很多，例如不想某些异常传给上层调用者，可以捕获之后重新显式抛出另外一种异常给调用者。

注意：throw 显式抛出的异常与系统生成并抛出的异常，在处理方式上没有区别，就是两种方法：要么捕获自己处理，要么抛出给上层调用者。

设计良好异常机制

考虑要在异常中存储什么额外状态——记住，异常也是对象；
Exception 类有四个公开的构造方法，一般情况下，自定义异常类时这四个构造方法都要实现，可用于初始化额外的状态，或者定制异常消息；
不要在你的 API 中自定义很多细致的异常类—— Java I/O 和反射 API 都因为这么做了而受人诟病，所以别让使用这些包时的情况变得更糟；
别在一个异常类型中描述太多状况——例如，实现 JavaScript 的 Nashorn 引擎（Java 8 新功能）一开始有超多粗制滥造的异常，不过在发布之前修正了。

异常在子类覆盖中的体现

子类覆盖父类时, 如果父类的方法抛出的异常,那么子类只能抛出父类异常或该异常的子类。
如果父类方法抛出多个异常, 那么子类在覆盖方法时，只能抛出父类异常的子集。
如果父类或接口的方法中没有异常抛出, 那么子类在覆盖方法时,也不可能抛出异常。如果子类方法发生异常，就必须进行 try 处理，绝对不能抛。

一句话就是父类限制了子类可抛出的异常。

有争议的两种处理异常的反模式

// 不要捕获异常而不处理
try {
    someMethodThatMightThrow();
} catch(Exception e){
}

// 不要捕获，记录日志后再重新抛出异常
try {
    someMethodThatMightThrow();
} catch(SpecificException e) {
    log(e);
    throw e;
}

第一个反模式直接忽略近乎一定需要处理的异常状况（甚至没有在日志中记录）。这么做会增大系统其他地方出现问题的可能性——出现问题的地方可能会离原来的位置很远。除非真的确定即使爆出异常，则可以忽略。

第二个反模式只会增加干扰——虽然记录了错误消息，但没真正处理发生的问题——在系统高层的某部分代码中还是要处理这个问题。一般的操作是在 catch 块中比如进行资源关闭的工作，然后可重新抛出异常。

讨论

对比受检和未受检异常

若想区分已检异常和未检异常，记住两点：异常是 Throwable 对象，而且异常主要分为两类，通过 Error 和 Exception 子类标识。只要异常对象是 Error 类，就是未检异常。Exception 类还有一个子类 RuntimeException ， RuntimeException 类的所有子类都属于未检异常。除此之外，都是已检异常。

提示：对于运行时异常通常不采用抛出或捕获处理方式，而是应该提前预判，防止这种发生异常，做到未雨绸缪。例如在进行除法运算之前应该判断除数是非零的，修改代码进行提前预判这样处理要比通过 try-catch 捕获异常要友好的多。

未受检异常和受检异常的区别如下：受检异常必须出现在 throws 语句中，调用者必须处理，Java 编译器会强制这一点，而未受检异常则没有这个要求。

为什么要有这个区分呢？我们自己定义异常的时候应该使用受检还是未受检异常呢？对于这个问题，业界有各种各样的观点和争论，没有特别一致的结论。

一种普遍的说法是：未受检异常表示编程的逻辑错误，编程时应该检查以避免这些错误，比如空指针异常，如果真的出现了这些异常，程序退出也是正常的，程序员应该检查程序代码的 bug 而不是想办法处理这种异常。受检异常表示程序本身没问题，但由于 I/O、网络、数据库等其他不可预测的错误导致的异常，调用者应该进行适当处理。

但其实编程错误也是应该进行处理的，尤其是 Java 被广泛应用于服务器程序中，不能因为一个逻辑错误就使程序退出。所以，目前一种更被认同的观点是：Java 中对受检异常和未受检异常的区分是没有太大意义的，可以统一使用未受检异常来代替。

这种观点的基本理由是：无论是受检异常还是未受检异常，无论是否出现在 throws 声明中，都应该在合适的地方以适当的方式进行处理，而不只是为了满足编译器的要求盲目处理异常，既然都要进行处理异常，受检异常的强制声明和处理就显得烦琐，尤其是在调用层次比较深的情况下。

其实观点本身并不太重要，更重要的是一致性，一个项目中，应该对如何使用异常达成一致，并按照约定使用。

参考

第 14 章　异常处理-图灵社区 http://www.ituring.com.cn/book/tupubarticle/17745
Java 编程的逻辑-微信读书 https://weread.qq.com/web/reader/b51320f05e159eb51b29226kc81322c012c81e728d9d180

acc8226

关注

3
点赞
踩
10

收藏

觉得还不错? 一键收藏
0
评论
09. Java 异常

有些公司为了提高代码的可重用性，自己开发了一些 Java 类库或框架，其中少不了自己编写了一些异常类。实现自定义异常类需要继承 Exception 类或其子类，如果自定义运行时异常类需继承 RuntimeException 类或其子类。我们通过继承 Exception 或者 RuntimeException 来定义一个异常。super();} }super();和很多其他异常类一样，我们没有定义额外的属性和代码，只是继承了Exception，定义了构造方法并调用了父类的构造方法。
复制链接

扫一扫