0002_Java笔记 Java的异常机制；Exception、Error区别；try、catch 和 finally；异常处理的两个基本原则；异常处理的性能开销；

学习目标：

1、Java的异常机制
2、Exception、Error
3、NoClassDefFoundError 和 ClassNotFoundException 区别
4、捕获异常：try、catch 和 finally
5、try-with-resources结构
6、multiple catch
7、抛出异常 throw、throws 关键字
8、自定义异常
9、异常处理的两个基本原则
10、Throw early, catch late 原则
11、Java异常处理的性能开销

---

学习结论：

Java的异常机制

异常：程序运行过程中发生的不正常事件，会中断程序运行。

Java 语言提供了相对完善的异常处理机制，这种机制大大降低了编写和维护可靠程序的门槛。

Java异常层级图：<别人画的图>

如果使用IDEA编译可以使用功能快捷键 Shift+Ctrl+Alt+U快速查看层级图。

---

Exception、Error区别

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

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

• Exception 是程序正常运行中，可以预料的意外情况，可能并且应该被捕获，进行相应处理。
• Error 是指在正常情况下，不大可能出现的情况，绝大部分的 Error 都会导致程序（比如 JVM 自身）处于非正常的、不可恢复状态。既然是非正常情况，所以不便于也不需要捕获，常见的比如 OutOfMemoryError 之类，都是 Error 的子类。

Exception 又分为可检查（checked）异常和不检查（unchecked）异常。

• 可检查异常在源代码里必须显式地进行捕获处理，这是编译期检查的一部分。Error是不可查，是 Throwable 不是 Exception。例如：IOException。
• 不检查异常就是所谓的运行时异常，类似 NullPointerException、ArrayIndexOutOfBoundsException 之类，通常是可以编码避免的逻辑错误，具体根据需要来判断是否需要捕获，并不会在编译期强制要求。

---

NoClassDefFoundError 和 ClassNotFoundException 区别

NoClassDefFoundError

NoClassDefFoundError是致命错误。当JVM在尝试执行以下操作时找不到类的定义时，就会发生这种情况：

使用new关键字实例化一个类
使用方法调用加载类
当编译器可以成功编译类但Java运行时无法找到类文件时，将发生错误。通常在执行静态块或初始化类的静态字段时发生异常时发生，因此类初始化失败。

让我们考虑一种方案，它是重现问题的一种简单方法。ClassWithInitErrors初始化引发异常。因此，当我们尝试创建ClassWithInitErrors对象时，它将引发ExceptionInInitializerError。

//如果尝试再次加载相同的类，则会得到NoClassDefFoundError：

public class ClassWithInitErrors {
    static int data = 1 / 0;
}
public class NoClassDefFoundErrorExample {
    public ClassWithInitErrors getClassWithInitErrors() {
        ClassWithInitErrors test;
        try {
            test = new ClassWithInitErrors();
        } catch (Throwable t) {
            System.out.println(t);
        }
        test = new ClassWithInitErrors();
        return test;
    }
}

//让我们为这种情况编写一个测试用例：
@Test(expected = NoClassDefFoundError.class)
public void givenInitErrorInClass_whenloadClass_thenNoClassDefFoundError() {
    NoClassDefFoundErrorExample sample = new NoClassDefFoundErrorExample();
    sample.getClassWithInitErrors();
}

ClassNotFoundException

ClassNotFoundException是一个检查的异常，当应用程序尝试通过其完全限定的名称加载类并且在类路径上找不到其定义时，将发生此异常。

这主要是在尝试使用Class.forName（），ClassLoader.loadClass（）或ClassLoader.findSystemClass（）加载类时发生的。
因此，在使用反射时，我们需要格外小心java.lang.ClassNotFoundException。

例如，让我们尝试在不添加必要依赖项的情况下加载JDBC驱动程序类，这将使我们获得ClassNotFoundException：

@Test(expected = ClassNotFoundException.class)
public void givenNoDrivers_whenLoadDriverClass_thenClassNotFoundException() 
  throws ClassNotFoundException {
      Class.forName("oracle.jdbc.driver.OracleDriver");
}

---

捕获异常：try、catch 和 finally

try-catch没啥可说的，但是一定要记得finally中的代码无论有无异常均要执行。

try {
    // 可能会发生异常的程序代码
} catch (Type1 id1){
    // 捕获并处置try抛出的异常类型Type1
} catch (Type2 id2){
     //捕获并处置try抛出的异常类型Type2
} finally {
	//无论有无异常都会执行finally中的代码
}

---

try-with-resources结构

Java语言还加入了一些新的特性。如：try-with-resources结构。在一些特定的场景使用。

try-with-resource 结构的用法。

private static void printFileJava7() throws IOException {
    try(FileInputStream input = new FileInputStream("file.txt")) {
        int data = input.read();
        while(data != -1){
            System.out.print((char) data);
            data = input.read();
        }
    }   
}

FileInputStream 类型变量就在try关键字后面的括号中声明。而且一个FileInputStream 类型被实例化并被赋给了这个变量。

当try语句块运行结束时，FileInputStream 会被自动关闭。这是因为FileInputStream 实现了java中的java.lang.AutoCloseable接口。所有实现了这个接口的类都可以在try-with-resources结构中使用。

java.lang.AutoCloseable中close方法。


FileInputStream 中的close方法。在finalize方法中调用。

回顾之前的学习，只是直到去学语法，其实我们应该经常这样去查看一下源码，便于知其然，知其所以然。

try-with-resources使用多个资源时，中间以；逗号隔开。

private static void printFileJava7() throws IOException {
    try(FileInputStream input = new FileInputStream("file.txt"); BufferedInputStream bufferedInput = new BufferedInputStream(input)){
	    int data = buffereInput.read();
	    while(data != -1){
	         System.out.println( (char) data);
	         data = bufferedInput.read();
	    }
    }
}

关于try-with-resources的一些知识，可以查看博客：https://www.cnblogs.com/barrywxx/p/9993005.html

resources结构经常使用在Java的IO场景 :InputStream，OutputStream，Reader，Writer 。

---

multiple catch

Multicatch关键字可以使单个catch块可以通过用|分隔每个catch块来捕获多个异常 （管道符号）在catch块。

try (BufferedReader br = new BufferedReader(…);
     BufferedWriter writer = new BufferedWriter(…)) {// Try-with-resources
// do something
catch ( IOException | XEception e) {// Multiple catch
   // Handle it
} 

---

抛出异常 throw、throws 关键字

throw

throw总是出现在函数体中，用来抛出一个Throwable类型的异常。程序会在throw语句后立即终止，它后面的语句执行不到。必须使用try-catch语句块或者try-catch-finally语句

public class TestException {
	public static void main(String[] args) {
		int a = 6;
		int b = 0;
		try {  
			if (b == 0) throw new ArithmeticException(); // 通过throw语句抛出异常
			System.out.println("a/b的值是：" + a / b);
		}
		catch (ArithmeticException e) { // catch捕捉异常
			System.out.println("程序出现异常，变量b不能为0。");
		}
		System.out.println("程序正常结束。");
	}
}

throws

Throws抛出异常的规则：

1. 如果是不可查异常（unchecked exception），即Error、RuntimeException或它们的子类，那么可以不使用throws关键字来声明要抛出的异常，编译仍能顺利通过，但在运行时会被系统抛出。
2. 必须声明方法可抛出的任何可查异常（checked exception）。即如果一个方法可能出现受可查异常，要么用try-catch语句捕获，要么用throws子句声明将它抛出，否则会导致编译错误
3. 仅当抛出了异常，该方法的调用者才必须处理或者重新抛出该异常。当方法的调用者无力处理该异常的时候，应该继续抛出，而不是囫囵吞枣。
4. 调用方法必须遵循任何可查异常的处理和声明规则。若覆盖一个方法，则不能声明与覆盖方法不同的异常。声明的任何异常必须是被覆盖方法所声明异常的同类或子类。

public class Shoot {
    static void pop()throws NegativeArraySizeException{
    	int[] arr = new int[-3];
    }
	public static void main(String[] args) {
		 try{
			 pop();
		 }catch(NegativeArraySizeException e){
			 System.out.println("pop()方法抛出的异常");
		 }
	}
}

---

自定义异常

有的时候，我们会根据需要自定义异常。必须继承Throwable的子类，如果是检查型异常，继承Exception类；运行是异常，继承RuntimeException.这个时候除了保证提供足够的信息，还有两点需要考虑：

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

class AddException extends Exception{
	public AddException(String msg) {
		super(msg);
	}
}
public class TestDemo {
 
	public static void main(String[] args) throws Exception {
		 if((10+20)==30) {
			 throw new AddException("错误的相加操作！不允许");		 }
}}

---

知识点拓展：

异常处理的两个基本原则

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

在你工作中是否经常出现上面代码。其实样写是不妥的。违反了异常处理的基本规则。

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

• 泛泛的 Exception 之类，恰恰隐藏了我们的目的。
• 我们也要保证程序不会捕获到我们不希望捕获的异常。比如，你可能更希望 RuntimeException 被扩散出来，而不是被捕获。
• 不要捕获 Throwable 或者 Error，这样很难保证我们能够正确程序处理 OutOfMemoryError。

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

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

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

try {
   // 业务代码
} catch (IOException e) {
    e.printStackTrace();//问题所在，在复杂分布式系统中，怎么判断日志输出到什么地方。
}

上面代码也是存在一定问题的。

• 稍微复杂一点的生产系统中，标准出错（STERR）不是个合适的输出选项，因为你很难判断出到底输出到哪里去了。
• 分布式系统，如果发生异常，但是无法找到堆栈轨迹（stacktrace），这纯属是为诊断设置障碍。所以，最好使用产品日志，详细地输出到日志系统里。

---

Throw early, catch late 原则

在发现问题的时候，第一时间抛出，能够更加清晰的反映问题。在处理异常的时候可以保留原有异常的cause信息
直接再抛出或者构建新的异常抛出去。

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

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

修改一下，让问题“throw early”，对应的异常信息就非常直观了。

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

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

---

Java异常处理的性能开销

• try-catch代码会产生额外的开销，影响JVM对代码的优化。
• 建议仅仅对有必要的代码段捕获
• 更不要一个try包括整段代码
• 更不要利用异常代码流程序，因为它的执行效率比条件语句if/else的效率低。
• Java每实例化一个Exception，都会对当时的堆栈进行快照，如果发生比较频繁，需要考虑性能开销。

---

Java 语言的 Checked Exception 也许是个设计错误，

列举了几点：

• Checked Exception 的假设是我们捕获了异常，然后恢复程序。但是，其实我们大多数情况下，根本就不可能恢复。Checked Exception 的使用，已经大大偏离了最初的设计目的。
• Checked Exception 不兼容 functional 编程，如果你写过 Lambda/Stream 代码，相信深有体会。

---

注意：关于Java异常处理机制，我也阅读了很多资料，暂时总结上面这么多。上面很多例子直接取自原文。希望能够帮助更多人去理解java异常机制。