Java核心技术36讲笔记：第二讲：Exception和Error有什么区别？

Exception 和 Error的区别？

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

Exception 是程序正常运行中，可以预料的意外情况，应该被捕获。Error 是正常运行中不大可能出现的情况，比如OutOfMemoryError等，不便也不需要捕获。

运行时异常与一般异常有什么区别？

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

编译时异常和运行时异常RuntimeException，前者通过捕获异常从而获取异常信息，后者主要通过规范代码开发、测试通过手段减少运行时异常的发生。

理解 Throwable、Exception、Error 的设计和分类

NoClassDefFoundError 和 ClassNotFoundException 有什么区别?

ClassNotFoundException的产生原因主要是：
Java支持使用反射方式在运行时动态加载类，例如使用Class.forName方法来动态地加载类时，可以将类名作为参数传递给上述方法从而将指定类加载到JVM内存中，如果这个类在类路径中没有被找到，那么此时就会在运行时抛出ClassNotFoundException异常。
解决该问题需要确保所需的类连同它依赖的包存在于类路径中，常见问题在于类名书写错误。
另外还有一个导致ClassNotFoundException的原因就是：当一个类已经某个类加载器加载到内存中了，此时另一个类加载器又尝试着动态地从同一个包中加载这个类。通过控制动态类加载过程，可以避免上述情况发生。

NoClassDefFoundError产生的原因在于：
如果JVM或者ClassLoader实例尝试加载（可以通过正常的方法调用，也可能是使用new来创建新的对象）类的时候却找不到类的定义。要查找的类在编译的时候是存在的，运行的时候却找不到了。这个时候就会导致NoClassDefFoundError.
造成该问题的原因可能是打包过程漏掉了部分类，或者jar包出现损坏或者篡改。解决这个问题的办法是查找那些在开发期间存在于类路径下但在运行期间却不在类路径下的类。

另：
ClassNotFoundException发生在装入阶段。
当应用程序试图通过类的字符串名称，使用常规的三种方法装入类，但却找不到指定名称的类定义时就抛出该异常。

NoClassDefFoundError： 当目前执行的类已经编译，但是找不到它的定义时
也就是说你如果编译了一个类B，在类A中调用，编译完成以后，你又删除掉B，运行A的时候那么就会出现这个错误

加载时从外存储器找不到需要的class就出现ClassNotFoundException
连接时从内存找不到需要的class就出现NoClassDefFoundError

重点区别，一个是加载时错误：ClassNotFoundException ，一个是连接时（已经编译完成）错误：NoClassDefFoundError。

ClassNotFoundException和NoClassDefFoundError的区别

另一个答案：
ClassNotFoundException occurs when the runtime is trying to find the class named by some String for example Class.forName(java.lang.String) method take a string argument and tries to find the class with this name. In this case the class-name is a sting and can only be checked at runtime. here the exception clearly says... this "class" is not found. So... it can happen for two reasons :

Reason 1. Class-name is not a valid java-class ( example - "java.bang.kiting").

// Example
Class cdef = Class.forName( "java.bang.kiting" );
Reason 2. Class-name is was a valid class... but somehow it was not packaged with the jar or is not resolved in class-path. So as far as the runtime knows... it can be a wrong class name... similar to case 1.

// Example
Class cdef =Class.forName( "apache.some.SomeLegitClass" );
Where as NoClassDefFoundError for cases where the actual class reference was used,

// example
import apache.some.SomeLegitClass
SomeLegitClass i = (SomeLegitClass) instanceOfSomeLegitClass;
So basically the everything was correct but somehow the class is not packaged with the jar ( or more generally - is not resolved in the class-path ). In this case we get NoClassDefFoundError.

Here runtime knows that the class is valid since it compiled successfully... but it can not find the "class definition".

ClassNotFoundException vs NoClassDefFoundError

方便的用法：try-with-resources 和 multiple catch

try-with-resources 和 multiple catch，具体可以参考下面的代码段。在编译时期，会自动生成相应的处理逻辑，比如，自动按照约定俗成 close 那些扩展了 AutoCloseable 或者 Closeable 的对象。

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

典型的错误用法

try {
  // 业务代码
  // …
  Thread.sleep(1000L);
} catch (Exception e) {
  // Ignore it（生吞异常）
}

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

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

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

不要使用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) {
	Objects. requireNonNull(filename);
	//...perform other operations... 
	InputStream in = new FileInputStream(filename);
	 //...read the preferences file...
}

Throw early，尽早抛出filename可能为空的这种异常。

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

异步异常的处理办法？

关于今天我们讨论的题目你做到心中有数了吗？可以思考一个问题，对于异常处理编程，不同的编程范式也会影响到异常处理策略，比如，现在非常火热的反应式编程（Reactive Stream），因为其本身是异步、基于事件机制的，所以出现异常情况，决不能简单抛出去；另外，由于代码堆栈不再是同步调用那种垂直的结构，这里的异常处理和日志需要更加小心，我们看到的往往是特定 executor 的堆栈，而不是业务方法调用关系。对于这种情况，你有什么好的办法吗？

答案一：
1.异常：这种情况下的异常，可以通过完善任务重试机制，当执行异常时，保存当前任务信息加入重试队列。重试的策略根据业务需要决定，当达到重试上限依然无法成功，记录任务执行失败，同时发出告警。
2.日志：类比消息中间件，处在不同线程之间的同一任务，简单高效一点的做法可能是用traceId/requestId串联。有些日志系统本身支持MDC/NDC功能，可以串联相关联的日志。

答案二：
一般各种异步编程框架都会对异常的传递和堆栈信息做处理吧？比如promise/future风格的。本质上大致就是把lambda中的异常捕获并封装，再进一步延续异步上下文，或者转同步处理时拿到原始的错误和堆栈信息。或者比如Future Stage之类使用ExecutionException的思路。

答案三：
业务功能模块分配ID，在记录日志是将前后模块的ID进行调用关系的串联，一并跟任务信息，进行日志保存。（和答案一类似）

Spring MVC全局异常处理的方式

使用Spring MVC统一异常处理实战