本篇文章为你整理了Java 中的异常处理机制（java中的异常处理机制）的详细内容，包含有java中的异常处理机制名词解释 java中的异常处理机制 java中的异常处理机制头歌 java异常处理机制属于什么模式 Java 中的异常处理机制，希望能帮助你了解 Java 中的异常处理机制。

　　 本篇文章主要介绍了1、Java 中的异常2、如何处理函数抛出的异常3、处理异常的原则4、异常处理时，性能开销大的地方

　　
Java 语言在设计之初就提供了相对完善的异常处理机制。

　　我们首先介绍一下 Java 中的异常。

　　介绍 Java 中的异常

　　异常是程序在运行过程中出现的程序异常事件，异常会中断正在执行的正常指令流 。

　　Java 中的异常分为两大类：Exception 和 Error。

　　下面是 Exception 和 Error 的类定义

public class Exception extends Throwable {}

　　public class Error extends Throwable {}

　　Exception 和 Error 都继承了 Throwable 类，在 Java 中只有 Throwable 类型的实例才可以被抛出（throw）或者被捕获（catch）。

　　Exception 和 Error 体现了 Java 平台设计者对不同异常情况的分类。

　　下面我们逐一介绍 Error 和 Exception。

　　介绍 Error

　　Error 类对象一般是由虚拟机生成并抛出，绝大部分的 Error 都会导致虚拟机自身处于不可恢复的状态，是程序无法控制和处理的。当出现 Error 时，一般会选择终止线程。

　　Error 中最常见的是虚拟机运行错误（VirtualMachineError 抽象类）。

　　虚拟机运行错误中最常见的有：

　　内存溢出（OutOfMemoryError）：由于内存不足，虚拟机没有可分配的内存了，垃圾回收器也不能释放更多的内存，那么虚拟机抛出 OutOfMemoryError

　　栈溢出（StackOverflowError）：如果一个线程已用的栈大小 超过 配置的允许最大的栈大小，那么虚拟机抛出 StackOverflowError

　　介绍 Exception

　　Exception 有两种类型「编译时异常」和「运行时异常」

　　「编译时异常」对应 Java 的 Exception 类

　　「运行时异常」对应 Java 的 RuntimeException 类（RuntimeException 类继承 Exception 类 ）

　　下面是 Exception、RuntimeException 类的定义

public class Exception extends Throwable {}

　　public class RuntimeException extends Exception {}

　　对于「运行时异常」，我们在编写代码的时候，可以不用主动去 try-catch 捕获（不强制要求），编译器在编译代码的时候，并不会检查代码是否有对运行时异常做了处理。

　　相反，对于「编译时异常」，我们在编写代码的时候，必须主动去 try-catch 获取 或者 在函数定义中声明向上抛出异常（throws），否则编译就会报错。

　　所以：

　　「运行时异常」也叫作非受检异常（Unchecked Exception）

　　「编译时异常」也叫作受检异常（Checked Exception）

　　在函数抛出异常的时候，，我们该怎么处理呢？是吞掉还是向上抛出？

　　如果选择向上抛出，我们应该选择抛出哪种类型的异常呢？是受检异常还是非受检异常？

　　我们下文会对此介绍。

　　常见的编译时异常有：

　　FileNotFoundException：当尝试打开由指定路径表示的文件失败时抛出

　　ClassNotFoundException：当应用程序尝试通过其字符串名称加载类失败时抛出，以下三种方法加载类：

　　Class.forName(java.lang.String)

　　ClassLoader.findSystemClass(java.lang.String)

　　ClassLoader.loadClass(java.lang.String, boolean)

　　
非法参数异常（IllegalArgumentException）：当传入了非法或不正确的参数时抛出

　　空指针异常（NullPointerException）：当在需要对象的情况下使用了 null 时抛出。

　　下标访问越界异常（IndexOutOfBoundsException）：当某种索引（例如数组，字符串或向量）的索引超出范围时抛出。

　　类型转换异常（ClassCastException）：当尝试将对象转换为不是实例的子类时抛出。

　　运算异常（ArithmeticException）：运算条件出现异常时抛出。例如，“除以零”的整数。

　　Java 异常类的结构

　　如何处理函数抛出的异常

　　在函数抛出异常的时候，我们该怎么处理呢？是吞掉还是向上抛出？

　　如果选择向上抛出，我们应该选择抛出哪种类型的异常呢？是受检异常还是非受检异常？

　　下面我们就对此介绍。

　　吞掉 or 抛出

　　在函数抛出异常的时候，我们该怎么处理？是吞掉还是向上抛出？

　　总结一下，在函数抛出异常的时候，一般有下面三种处理方法。

　　原封不动地 re-throw

　　包装成新的异常 re-throw

　　
原封不动地 re-throw。具体的代码示例如下所示：

public void func1() throws Exception1 {

　　 // ...

　　//原封不动的re-throw Exception1

　　public void func2() throws Exception1 {

　　 //...

　　 func1();

　　 //...

　　包装成新的异常 re-throw。具体的代码示例如下所示：

public void func1() throws Exception1 {

　　 // ...

　　public void func2() throws Exception2 {

　　 //...

　　 try {

　　 func1();

　　 } catch (Exception1 e) {

　　 // wrap成新的Exception2然后re-throw

　　 throw new Exception2("...", e);

　　 //...

　　当我们面对函数抛出异常的时候，应该选择上面的哪种处理方式呢？我总结了下面三个参考原则：

　　如果 func1() 抛出的异常是可以恢复，且 func2() 的调用方并不关心此异常，我们完全可以在 func2() 内将 func1() 抛出的异常吞掉；

　　如果 func1() 抛出的异常对 func2() 的调用方来说，也是可以理解的、关心的 ，并且在业务概念上有一定的相关性，我们可以选择直接将 func1 抛出的异常 re-throw；

　　如果 func1() 抛出的异常太底层，对 func2() 的调用方来说，缺乏背景去理解、且业务概念上无关，我们可以将它重新包装成调用方可以理解的新异常，然后 re-throw。

　　应该选择上面的哪种处理方式，总结来说就是从以下两个方面进行判断：

　　函数1 抛出的异常是否可以恢复

　　函数1 抛出的异常对于 函数2 的调用方来说是否可以理解、关心、业务概念相关

　　总之，是否往上继续抛出，要看上层代码是否关心这个异常。关心就将它抛出，否则就直接吞掉。

　　是否需要包装成新的异常抛出，看上层代码是否能理解这个异常、是否业务相关。如果能理解、业务相关就可以直接抛出，否则就封装成新的异常抛出。

　　对于处理函数抛出的异常，我们需要注意：

　　如果选择吞掉函数抛出的异常的话，我们必须把异常输出到日志系统，方便后续诊断。

　　如果把异常输出到日志系统时，我们在保证诊断信息足够的同时，也要考虑避免包含敏感信息，因为那样可能导致潜在的安全问题。

　　如果我们看 Java 的标准类库，你可能注意到类似 java.net.ConnectException，出错信息是类似“ Connection refused (Connection refused)”，而不包含具体的机器名、IP、端口等，一个重要考量就是信息安全。

　　类似的情况在日志中也有，比如，用户数据一般是不可以输出到日志里面的。

　　受检异常 or 非受检异常

　　在函数抛出异常的时候，如果选择向上抛出，我们应该选择抛出哪种类型的异常呢？是受检异常还是非受检异常？

　　对于代码 bug（比如下标访问越界、空指针）以及不可恢复的异常（比如数据库连接失败），即便我们捕获了，也做不了太多事情，我们希望程序能 fail-fast，所以，我们倾向于使用非受检异常，将程序终止掉。

　　对于可恢复异常、业务异常，比如提现金额大于余额的异常，我们更倾向于使用受检异常，明确告知调用者需要捕获处理。

　　处理异常的原则

　　尽量不要捕获通用异常

　　尽量不要捕获类似 Exception 这样的通用异常，而应该捕获特定异常（尽量缩小捕获的异常范围）。

　　下面举例说明，实例代码如下：

try {

　　 // 业务代码

　　 // …

　　 Thread.sleep(1000L);

　　} catch (Exception e) {

　　 // Ignore it

　　对于 Thread.sleep() 函数抛出的 InterruptedException，我们不应该捕获 Exception 通用异常，而应该捕获 InterruptedException 这样的特定异常。

　　这是因为我们要保证程序不会捕获到我们不希望捕获的异常。比如，我们更希望 RuntimeException 导致线程终止，而不是被捕获。

　　不要生吞异常

　　不要生吞（swallow）异常，尽量把异常信息记录到日志系统中。

　　这是异常处理中要特别注意的事情，因为生吞异常很可能会导致难以诊断的诡异情况。

　　如果我们没有把异常抛出，也没有把异常记录到日志系统，程序可能会在后续出现难以排查的 bug。没人能够轻易判断究竟是哪里抛出了异常，以及是什么原因产生了异常。

　　再来看一段代码

try {

　　 // 业务代码

　　 // …

　　} catch (IOException e) {

　　 e.printStackTrace();

　　这段代码作为一段实验代码，是没有任何问题的，但是在产品代码中，通常都不允许这样处理。

　　你先思考一下这是为什么呢？

　　我们先来看看 printStackTrace() 的文档，开头就是“Prints this throwable and its backtrace to the standard error stream”。问题就在这里，在稍微复杂一点的生产系统中，标准出错（STERR）不是个合适的输出选项，因为你很难判到底输出到哪里去了。尤其是对于分布式系统，如果发生异常，但是无法找到堆栈轨迹（stacktrace），这纯属是为诊断设置障碍。

　　所以，最好使用产品日志，详细地将异常记录到日志系统里。

　　异常处理时，性能开销大的地方

　　我们从性能角度来审视一下 Java 的异常处理机制，这里有两个性能开销相对大的地方：

　　try-catch 代码段会产生额外的性能开销，或者换个角度说，它往往会影响 JVM 对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的 try 包住整段的代码；

　　Java 每实例化一个 Exception，都会对当时的栈进行快照，这是一个相对比较重的操作。如果实例化 Exception 发生的非常频繁，这个开销可就不能被忽略了。

　　当我们的服务出现反应变慢、吞吐量下降的时候，检查发生最频繁的 Exception 也是一种思路。

　　Exception和Error有什么区别？

　　程序出错该返回啥？NULL、异常、错误码、空对象？

　　以上就是Java 中的异常处理机制（java中的异常处理机制）的详细内容，想要了解更多 Java 中的异常处理机制的内容，请持续关注盛行IT软件开发工作室。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。