Exception和Error有什么区别

最新推荐文章于 2024-05-11 10:24:57 发布

决决怪

最新推荐文章于 2024-05-11 10:24:57 发布

阅读量3.7k

点赞数 2

分类专栏：面试 java核心技术文章标签： java

原文链接：https://blog.csdn.net/weixin_42124070/article/details/80833629

版权

面试同时被 2 个专栏收录

10 篇文章 0 订阅

订阅专栏

java核心技术

3 篇文章 0 订阅

订阅专栏

基本概念

首先Exception和Error都是继承于Throwable 类，在 Java 中只有 Throwable 类型的实例才可以被抛出（throw）或者捕获（catch），它是异常处理机制的基本组成类型。

Exception和Error体现了JAVA这门语言对于异常处理的两种方式。

Exception是java程序运行中可预料的异常情况，咱们可以获取到这种异常，并且对这种异常进行业务外的处理。

Error是java程序运行中不可预料的异常情况，这种异常发生以后，会直接导致JVM不可处理或者不可恢复的情况。所以这种异常不可能抓取到，比如OutOfMemoryError、NoClassDefFoundError等。

其中的Exception又分为检查性异常和非检查性异常。两个根本的区别在于，检查性异常 必须在编写代码时，使用try catch捕获（比如：IOException异常）。非检查性异常 在代码编写使，可以忽略捕获操作（比如：ArrayIndexOutOfBoundsException），这种异常是在代码编写或者使用过程中通过规范可以避免发生的。切记，Error是Throw不是Exception 。

使用场景

以上的分析 Exception 和 Error 的区别，是从概念角度考察了 Java 处理机制。总的来说，还处于理解的层面，面试者只要阐述清楚就好了。

我们在日常编程中，如何处理好异常是比较考验功底的，我觉得需要掌握两个方面

第一，理解 Throwable、Exception、Error 的设计和分类。比如，掌握那些应用最为广泛的子类，以及如何自定义异常等。

一般在面试的情况下，都会问你，你知道Error和Exception下的子类有哪些？能说一下他们具体的应用场景？

其中有一个比较经典的面试题目，就是 NoClassDefFoundError 和 ClassNotFoundException 有什么区别

<span style="color:#000000"><code>区别一： <span style="color:#009900 !important">NoClassDefFoundError</span>它是<span style="color:#009900 !important">Error</span>，<span style="color:#009900 !important">ClassNotFoundException</span>是
<span style="color:#009900 !important">Exception</span>。

区别二：还有一个区别在于<span style="color:#009900 !important">NoClassDefFoundError</span>是<span style="color:#009900 !important">JVM</span>运行时通过classpath加载类
时，找不到对应的类而抛出的错误。<span style="color:#009900 !important">ClassNotFoundException</span>是在编译过程中如果可能出现此异常，在编译过程中必须将<span style="color:#009900 !important">ClassNotFoundException</span>异常抛出！

<span style="color:#009900 !important">NoClassDefFoundError</span>发生场景如下：
    <span style="color:#006666 !important">1</span>、类依赖的<span style="color:#000088 !important">class</span>或者<span style="color:#4f4f4f !important">jar</span>不存在 （简单说就是<span style="color:#4f4f4f !important">maven</span>生成运行包后被篡改）
    <span style="color:#006666 !important">2</span>、类文件存在，但是存在不同的域中 （简单说就是引入的类不在对应的包下)
    <span style="color:#006666 !important">3</span>、大小写问题，javac编译的时候是无视大小的，很有可能你编译出来的<span style="color:#000088 !important">class</span>文件就与想要的不一样！这个没有做验证


    <span style="color:#009900 !important">ClassNotFoundException</span>发生场景如下：
    <span style="color:#006666 !important">1</span>、调用<span style="color:#000088 !important">class</span>的<span style="color:#4f4f4f !important">forName</span>方法时，找不到指定的类
    <span style="color:#006666 !important">2</span>、<span style="color:#009900 !important">ClassLoader</span> 中的 findSystemClass() 方法时，找不到指定的类

举例说明如下<span style="color:#009900 !important">:</span>
    <span style="color:#009900 !important">Class</span>.forName(<span style="color:#009900 !important">"abc"</span>); 比如abc这个类不存项目中，代码编写时，就会提示此异常是检查性异常，比如将此异常抛出。

</code></span>

第二，理解 Java 语言中操作 Throwable 的元素和实践。掌握最基本的语法是必须的，如 try-catch-finally 块，throw、throws 关键字等。与此同时，也要懂得如何处理典型场景。

throw是存在于方法的代码块中，而throws是存在于方法外围，一般是在方法名后边 throws XXXException;

有个重要的点需要记住，就是try-catch-finally中rerun的执行顺序问题

<span style="color:#000000"><code class="language-java">
<span style="color:#000088 !important">try</span>{
    retrun <span style="color:#006666 !important">3</span>;
}<span style="color:#000088 !important">catch</span>{
    e.printStackTrace();
}<span style="color:#000088 !important">finally</span>{
    <span style="color:#000088 !important">return</span> <span style="color:#006666 !important">4</span>;
}

<span style="color:#880000 !important"><em>//上边情况下，实际返回的是4；</em></span>

<span style="color:#000088 !important">try</span>{
    <span style="color:#000088 !important">int</span> x = <span style="color:#006666 !important">3</span>;
    retrun x;
}<span style="color:#000088 !important">catch</span>{
    e.printStackTrace();
}<span style="color:#000088 !important">finally</span>{
    x++;
}

<span style="color:#880000 !important"><em>//上边情况下，实际返回的3；</em></span></code></span>

这是为什么呢？因为finally的业务操作是在try业务操作的return返回调用者者之前执行。按照刚才第一种情况，实际情况是，执行完try中的业务逻辑就，return返回的操作会先存储到一个临时的堆栈中，此时不给调用者返回，随后执行finally中的业务代码。如果finally中有return操作，那么就会把finally中的return值与try中的return值进行替换。随后将最终数据返回给调用者。

知识扩展
前面谈的大多是概念性的东西，下面我来谈些实践中的选择，我会结合一些代码用例进行分析。

先开看第一个吧，下面的代码反映了异常处理中哪些不当之处？

<span style="color:#000000"><code class="language-java"><span style="color:#000088 !important">try</span> {
  <span style="color:#880000 !important"><em>// 业务代码</em></span>
  <span style="color:#880000 !important"><em>// …</em></span>
  Thread.sleep(<span style="color:#006666 !important">1000</span>L);
} <span style="color:#000088 !important">catch</span> (Exception e) {
  <span style="color:#880000 !important"><em>// Ignore it</em></span>
}
</code></span>

这段代码虽然很短，但是已经违反了异常处理的两个基本原则。

第一，尽量不要捕获类似 Exception 这样的通用异常，而是应该捕获特定异常，在这里是 Thread.sleep() 抛出的 InterruptedException。

这是因为在日常的开发和合作中，我们读代码的机会往往超过写代码，软件工程是门协作的艺术，所以我们有义务让自己的代码能够直观地体现出尽量多的信息，而泛泛的 Exception 之类，恰恰隐藏了我们的目的。另外，我们也要保证程序不会捕获到我们不希望捕获的异常。比如，你可能更希望 RuntimeException 被扩散出来，而不是被捕获。

进一步讲，除非深思熟虑了，否则不要捕获 Throwable 或者 Error，这样很难保证我们能够正确程序处理 OutOfMemoryError。

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

生吞异常，往往是基于假设这段代码可能不会发生，或者感觉忽略异常是无所谓的，但是千万不要在产品代码做这种假设！

如果我们不把异常抛出来，或者也没有输出到日志（Logger）之类，程序可能在后续代码以不可控的方式结束。没人能够轻易判断究竟是哪里抛出了异常，以及是什么原因产生了异常。

再来看看第二段代码

<span style="color:#000000"><code class="language-java"><span style="color:#000088 !important">try</span> {
   <span style="color:#880000 !important"><em>// 业务代码</em></span>
   <span style="color:#880000 !important"><em>// …</em></span>
} <span style="color:#000088 !important">catch</span> (IOException e) {
    e.printStackTrace();
}</code></span>

这段代码作为一段实验代码，它是没有任何问题的，但是在产品代码中，通常都不允许这样处理。你先思考一下这是为什么呢？

这样的代码在代码规范中是没有问题的，他的问题出在，异常中的异常日志如何输出的问题。按照上边的输出，如果实在复杂的系统中，会判断不出来，异常具体在哪里打印出来的。
尤其是对于分布式系统，如果发生异常，但是无法找到堆栈轨迹（stacktrace），这纯属是为诊断设置障碍。所以，最好使用产品日志，详细地输出到日志系统里

我们接下来看下面的代码段，体会一下Throw early, catch late 原则。

<span style="color:#000000"><code class="language-java"><span style="color:#880000 !important"><em>//正常业务代码</em></span>
<span style="color:#000088 !important">public</span> <span style="color:#000088 !important">void</span> <span style="color:#009900 !important">readPreferences</span>(String fileName){
     <span style="color:#880000 !important"><em>//...perform operations... </em></span>
    InputStream in = <span style="color:#000088 !important">new</span> FileInputStream(fileName);
     <span style="color:#880000 !important"><em>//...read the preferences file...</em></span>
}

<span style="color:#880000 !important"><em>//“throw early” 原则后的业务代码</em></span>
<span style="color:#000088 !important">public</span> <span style="color:#000088 !important">void</span> <span style="color:#009900 !important">readPreferences</span>(String filename) {
    <span style="color:#880000 !important"><em>//先让可能出现的异常抛出来。</em></span>
    Objects. requireNonNull(filename);
    <span style="color:#880000 !important"><em>//...perform other operations... </em></span>
    InputStream in = <span style="color:#000088 !important">new</span> FileInputStream(filename);
     <span style="color:#880000 !important"><em>//...read the preferences file...</em></span>
}

</code></span>

至于“catch late”，其实是我们经常苦恼的问题，捕获异常后，需要怎么处理呢？
有很多同学，就直接生吞异常，本质上其实是掩盖问题。如果实在不知道如何处理，可以选择保留原有异常的 cause 信息，直接再抛出或者构建新的异常抛出去。在更高层面，因为有了清晰的（业务）逻辑，往往会更清楚合适的处理方式是什么。
还有一种处理方式，可自定义异常，将业务异常转换为业务术语，但是抛出异常时，必须把异常的cause信息打印出，方便跟踪问题，在最短的时间内，解决问题。但是需要考虑两点

自定异常时，需要考虑自定义异常是否为检查性异常，因为这种类型设计的初衷更是为了从异常情况恢复，作为异常设计者，我们往往有充足信息进行分类。
在保证诊断信息足够的同时，也要考虑避免包含敏感信息，因为那样可能导致潜在的安全问题。如果我们看 Java 的标准类库，你可能注意到类似 java.net.ConnectException，出错信息是类似“ Connection refused (Connection refused)”，而不包含具体的机器名、IP、端口等，一个重要考量就是信息安全。类似的情况在日志中也有，比如，用户数据一般是不可以输出到日志里面的。

对于异常中的检查性异常，我们简单的说一下。目前检查性异常被业界说是java的一种设计缺陷。有一下几点可以参考一下

Checked Exception 的假设是我们捕获了异常，然后恢复程序。但是，其实我们大多数情况下，根本就不可能恢复。Checked Exception 的使用，已经大大偏离了最初的设计目的。
当然，很多人也觉得没有必要矫枉过正，因为确实有一些异常，比如和环境相关的 IO、网络等，其实是存在可恢复性的，而且 Java 已经通过业界的海量实践，证明了其构建高质量软件的能力。

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

try-catch 代码段会产生额外的性能开销，或者换个角度说，它往往会影响 JVM 对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的 try 包住整段的代码；与此同时，利用异常控制代码流程，也不是一个好主意，远比我们通常意义上的条件语句（if/else、switch）要低效。
java 每实例化一个 Exception，都会对当时的栈进行快照，这是一个相对比较重的操作。如果发生的非常频繁，这个开销可就不能被忽略了。

所以，对于部分追求极致性能的底层类库，有种方式是尝试创建不进行栈快照的 Exception。这本身也存在争议，因为这样做的假设在于，我创建异常时知道未来是否需要堆栈。问题是，实际上可能吗？小范围或许可能，但是在大规模项目中，这么做可能不是个理智的选择。如果需要堆栈，但又没有收集这些信息，在复杂情况下，尤其是类似微服务这种分布式系统，这会大大增加诊断的难度。

当我们的服务出现反应变慢、吞吐量下降的时候，检查发生最频繁的 Exception 也是一种思路。关于诊断后台变慢的问题，我会在后面的 Java 性能基础模块中系统探讨。

以上介绍的就是异常的基本知识，和日常编码中的见解。但是随着 微服务 概念的日渐成熟，异常在微服务中的处理方式，也不能像普通项目。
当执行异常时，保存当前任务信息加入重试队列。重试的策略根据业务需要决定，当达到重试上限依然无法成功，记录任务执行失败，同时发出告警。
同时需要将微服务中的业务异常日志，进行记录，这种记录一般会跟随着唯一标识，方便在微服务项目中，定位问题