该怎么去理解java中的异常

怎么理解java中的异常：

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

Exception ：

• [1] 是程序正常运行中，可以预料的意外情况，可能并且应该被捕获，进行相应处理。

而Exception 分为检查性异常和非检查性异常

• [1] 检查性异常 必须在编写代码时，使用try catch捕获（比如：IOException异常）
• [2] 非检查性异常 在代码编写使，可以忽略捕获操作（比如：ArrayIndexOutOfBoundsException），这种异常是在代码编写或者使用过程中通过规范可以避免发生的。

Error ：

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

---

try-catch-finally 、throw、throws：

Java 语言中常见的操作 Throwable 的元素和实践

try-catch-finally ：

  try {
			System.out.println("kk");
			throw new Exception("kk测试");
		} catch (Exception e) {
			System.out.println("catch");
		} finally {
			System.out.println("finally");

• 通常都是通过 try-catch-finally 进行异常捕获，或者是在 finally 里面做一些资源回收工作。finally 往往是最后才执行

throw、throws：

throw

• [1] throw是语句抛出一个异常，一般是在代码块的内部，当程序 现某种逻辑错误时由程序员主动抛出某种特定类型的异常
• [2] 定义在方法体内
• [3] 创建的是一个异常对象
• [4] 确定了发生哪种异常才可以使用

throws

• [1] 在方法参数列表后，throws后可以跟着多个异常名，表示抛出的异常用逗号隔开
• [2] 表示向调用该类的位置抛出异常，不在该类解决

throw：在方法体内抛出自己创建的异常对象； throws：在方法名上抛出可能的异常类，方便其他人调用该方法时知晓。若throws抛出的是检查时异常，则强制后来的调用者处理该异常。

---

异常处理的两个基本原则：

原则一：尽量不要捕获类似 Exception 这样的通用异常，而是应该捕获特定异常

  try {
			System.out.println("kk");
			 throw new NullPointerException();
		} catch (Exception e) {
			System.out.println("catch");
		} finally {
			System.out.println("finally");

这是因为在日常的开发和合作中，读代码的机会往往超过写代码，有义务让自己的代码能够直观地体现出尽量多的信息，而泛泛的Exception恰恰隐藏了我们的目的

另外，要保证程序不会捕获到不希望捕获的异常。比如，可能更希望RuntimeException被扩散出来，而不是被捕获

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

原则二：不要生吞（swallow）异常。

  try {
			System.out.println("kk");
			 throw new NullPointerException();
		} catch (Exception e) {
		
		} 

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

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

---

异常处理Throw early, catch late原则：

再来看看第二段代码

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

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

看看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只是作为例子，实际产品代码中可能是各种情况，比如获取配置失败之类的。在发现问题的时候，第一时间抛出，能够更加清晰地反映问题

可以修改一下，让问题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代码段会产生额外的性能开销
换个角度说，try-catch往往会影响JVM对代码进行优化，所以建议仅捕获有必要的代码段，尽量不要一个大的try包住整段的代码

与此同时，利用异常控制代码流程，也不是一个好主意，远比通常意义上的条件语句(if/else、switch)要低效

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

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

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

综上，从一个常见的异常处理概念问题，简单总结Java异常处理的机制，并结合代码分析了一些普遍认可的最佳实践，以及业界最新的一些异常使用共识。最后，分析了异常性能开销

---

经典面试题：NoClassDefFoundError 和 ClassNotFoundException 有什么区别

区别一： NoClassDefFoundError它是Error，ClassNotFoundException是Exception。

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

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

ClassNotFoundException发生场景如下：
1、调用class的forName方法时，找不到指定的类
2、ClassLoader 中的 findSystemClass() 方法时，找不到指定的类