必须要清楚Exception和Error有什么区别

关注“Java后端技术全栈”

回复“面试”获取最新资料

无BUG

送你一张符，愿你程序永无BUG。

世界上存在永远不会出错的程序吗？也许这只会出现在程序员的梦中。随着编程语言和软件的诞生，异常情况就如影随形地纠缠着我们，只有正确处理好意外情况，才能保证程序的可靠性。Java 语言在设计之初就提供了相对完善的异常处理机制，这也是 Java 得以大行其道的原因之一，因为这种机制大大降低了编写和维护可靠程序的门槛。如今，异常处理机制已经成为现代编程语言的标配。

不管是应对面试还工作，对于异常处理机制是必须掌握的。

重点

Exception 和 Error 都是继承了 Throwable 类，在 Java 中只有 Throwable 类型的实例才可以被抛出（throw）或者捕获（catch），它是异常处理机制的基本组成类型。Exception 和 Error 体现了 Java 平台设计者对不同异常情况的分类。Exception 是程序正常运行中，可以预料的意外情况，可能并且应该被捕获，进行相应处理。Error 是指在正常情况下，不大可能出现的情况，绝大部分的 Error 都会导致程序（比如 JVM 自身）处于非正常的、不可恢复状态。既然是非正常情况，所以不便于也不需要捕获，常见的比如 OutOfMemoryError 之类，都是 Error 的子类。Exception 又分为可检查（checked）异常和不检查（unchecked）异常，可检查异常在源代码里必须显式地进行捕获处理，这是编译期检查的一部分。前面我介绍的不可查的 Error，是 Throwable 不是 Exception。不检查异常就是所谓的运行时异常，类似 NullPointerException、ArrayIndexOutOfBoundsException 之类，通常是可以编码避免的逻辑错误，具体根据需要来判断是否需要捕获，并不会在编译期强制要求。

下面简单列出一个大概的类图：

Java异常继承体系

关键字

try        

用于监听。将要被监听的代码(可能抛出异常的代码)放在try语句块之内，当try语句块内发生异常时，异常就被抛出。

catch  

用于捕获异常。catch用来捕获try语句块中发生的异常。

finally  

finally语句块总是会被执行。它主要用于回收在try块里打开的物力资源(如数据库连接、网络连接和磁盘文件)。只有finally块，执行完成之后，才会回来执行try或者catch块中的return或者throw语句，如果finally中使用了return或者throw等终止方法的语句，则就不会跳回执行，直接停止。

throw  

用于抛出异常。

throws

用在方法签名中，用于声明该方法可能抛出的异常。主方法上也可以使用throws抛出。如果在主方法上使用了throws抛出，就表示在主方法里面可以不用强制性进行异常处理，如果出现了异常，就交给JVM进行默认处理，则此时会导致程序中断执行。

关键字的使用案例

//以下指示使用demo。需要调整的地方请自行调整
public class ExceptionDemo {
   public void demo() {
       try {
           //业务代码
      } catch (Exception ex) {
           //打印日志或抛出其他类型异常
      }
  }

   public void demo1() {
       try {
           //业务代码
      } catch (Exception ex) {
           //打印日志或抛出其他类型异常
      } catch (Exception1 ex) {
         //打印日志或抛出其他类型异常
      }
  }

   public void demo2() {
       try {
           //业务代码
      } catch (Exception ex) {
           //打印日志或抛出其他类型异常
      } finally {
           //释放资源
      }
  }

   public void demo3() {
       try {
           //业务代码
      } catch (Exception ex) {
           //打印日志或抛出其他类型异常
      } catch (Exception1 ex) {
           //打印日志或抛出其他类型异常
      } finally {
           //释放资源
      }
  }
   //通常在使用到锁的场景中最常用的，然后在finally中释放锁
   public void demo4() {
       try {
           //业务代码
      } finally {
           //释放资源
      }
  }
   //自定义异常CustomException的使用
   //关于自定义异常，稍后会介绍
   public void demo5() {
       boolean flag = 0 > 1;
       if (flag) {
           //抛出一个自定义异常CustomException
          throw new CustomException("见鬼了，0居然大于1了");
      }
  }

   //通过throws抛出异常Exception
   public void demo6() throws Exception{
       //业务代码
  }
   //JDK1.8可以使用多异常捕获的方式
   public void demo7() {
       try {
           //业务代码
      } catch (xxxException | yyyException | zzzException e){
           //打印日志或抛出其他类型异常
      }
  }
}

建议

我们在日常开发中，如何处理好Java异常是比较考验你的Java基础功底的，我觉得需要掌握两个方面。

第一，理解 Throwable、Exception、Error 的设计和分类。

比如，掌握那些应用最为广泛的子类，以及如何自定义异常等。对于入门级别的小伙伴，我在这里建议你最好重点研究一下NoClassDefFoundError 、ClassNotFoundException 、ArrayIndexOutOfBoundsException等这些常见异常有什么区别。

第二，理解 Java 语言中操作 Throwable 的元素和实践。

掌握最基本的语法是必须的，如 try-catch-finally 块，throw、throws 关键字等。与此同时，也要懂得如何处理典型场景。

实战场景

场景一

下面的代码反映了异常处理中哪些不当之处？

try {
   // 业务代码
   Thread.sleep(1000L);
} catch (Exception e) {
   // Ignore it
}

在Thread类中sleep方法源码

public static native void sleep(long millis) throws InterruptedException;

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

第一，尽量不要捕获类似 Exception 这样的通用异常，而是应该捕获特定异常，在这里是 Thread.sleep() 抛出的 InterruptedException。这是因为在日常的开发和合作中，我们读代码的机会往往超过写代码，软件工程是门协作的艺术，所以我们有义务让自己的代码能够直观地体现出尽量多的信息，而泛泛的 Exception 之类，恰恰隐藏了我们的目的。另外，我们也要保证程序不会捕获到我们不希望捕获的异常。比如，你可能更希望 RuntimeException 被扩散出来，而不是被捕获。进一步讲，除非深思熟虑了，否则不要捕获 Throwable 或者 Error，这样很难保证我们能够正确程序处理 OutOfMemoryError。

第二，不要生吞（swallow）异常。这是异常处理中要特别注意的事情，因为很可能会导致非常难以诊断的诡异情况。生吞异常，往往是基于假设这段代码可能不会发生，或者感觉忽略异常是无所谓的，但是千万不要在产品代码做这种假设！如果我们不把异常抛出来，或者也没有输出到日志（Logger）之类，程序可能在后续代码以不可控的方式结束。没人能够轻易判断究竟是哪里抛出了异常，以及是什么原因产生了异常。

场景二

try {
  // 业务代码
} catch (IOException e) {
 e.printStackTrace();
}

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

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

每个项目打印日志方式可能不同，对于新手的话，看看你们项目里是怎么打印的就跟着使用就好了，最好是问问项目中技术好点的人，问问他们是如何打印错误日志的，需要注意些什么。但是也要注意使用日志的级别。对于有工作经验的话，通常是考虑选择哪种日志打印框架来处理，这里就不展开说了。

场景三

体会一下 Throw early, catch late 原则。

public void readPreferences(String fileName){
  //...perform operations...
 InputStream in = new FileInputStream(fileName);
  //...read the preferences file...
}

如果 fileName 是 null，那么程序就会抛出 NullPointerException，但是由于没有第一时间暴露出问题，堆栈信息可能非常令人费解，往往需要相对复杂的定位。这个 NPE 只是作为例子，实际产品代码中，可能是各种情况，比如获取配置失败之类的。在发现问题的时候，第一时间抛出，能够更加清晰地反映问题。

可以对场景三的代码进行稍微的调整

public void readPreferences(String filename) {
 Objects. requireNonNull(filename);
 //...perform other operations...
 InputStream in = new FileInputStream(filename);
  //...read the preferences file...
}

至于“catch late”，其实是我们经常苦恼的问题，捕获异常后，需要怎么处理呢？最差的处理方式，就是我前面提到的“生吞异常”，本质上其实是掩盖问题。如果实在不知道如何处理，可以选择保留原有异常的 cause 信息，直接再抛出或者构建新的异常抛出去。在更高层面，因为有了清晰的（业务）逻辑，往往会更清楚合适的处理方式是什么。

自定义异常

有的时候，我们会根据需要自定义异常，这个时候除了保证提供足够的信息，还有两点需要考虑：是否需要定义成 Checked Exception，因为这种类型设计的初衷更是为了从异常情况恢复，作为异常设计者，我们往往有充足信息进行分类。在保证诊断信息足够的同时，也要考虑避免包含敏感信息，因为那样可能导致潜在的安全问题。如果我们看 Java 的标准类库，你可能注意到类似 java.net.ConnectException，出错信息是类似“ Connection refused (Connection refused)”，而不包含具体的机器名、IP、端口等，一个重要考量就是信息安全。类似的情况在日志中也有，比如，用户数据一般是不可以输出到日志里面的。业界有一种争论（甚至可以算是某种程度的共识），Java 语言的 Checked Exception 也许是个设计错误，反对者列举了几点：Checked Exception 的假设是我们捕获了异常，然后恢复程序。但是，其实我们大多数情况下，根本就不可能恢复。Checked Exception 的使用，已经大大偏离了最初的设计目的。Checked Exception 不兼容 functional 编程，如果你写过 Lambda/Stream 代码，相信深有体会。很多开源项目，已经采纳了这种实践，比如 Spring、Hibernate 等，甚至反映在新的编程语言设计中，比如 Scala 等。

比如Spring中的aop下的一个自定义异常

package org.aopalliance.aop;
public class AspectException extends RuntimeException {
public AspectException(String message) {
super(message);
}
public AspectException(String message, Throwable cause) {
super(message, cause);
}
}

作为开发人员，可能大部分都是些业务代码，并且还有可能抛出一个自定义异常有一定的业务意义。

下面来一个简单版的自定义异常

public class CustomException extends RuntimeException{
   /**
    * 异常编码
    * 异常捕获到后针对每种code做不同的处理
    */
   private Integer code;

   /**
    * 附加数据
    */
   private Object data;
   //errorMsg可以设置为自定义的错误提示或业务提示
   public CustomException(String errorMsg) {
       super(errorMsg);
       this.code= 0;
  }

   public CustomException(String errorMsg, Integer code) {
       super(errorMsg);
       this.code = code;
  }

   public CustomException(Integer code, String errorMsg, Throwable errorCourse) {
       super(errorMsg,errorCourse);
       this.code = code;
  }

   public CustomException(String message, Integer code, Object data) {
       super(message);
       this.code = code;
       this.data = data;
  }
   //get set
}

基本上每个项目多多少少都会涉及到自定义异常，请看你的项目中exception目录下。对于自定义异常的使用在前面的案例中已有。

推荐阅读

目前10000+ 人已关注我们