Exception和Error的相关分析
Exception和Error继承关系图
我们可以看到Exception和Error都是继承自Throwable,在Java中只有Throwable类型的实例才可以被抛出(Throw)或者捕获(catch)，它是异常处理机制的基本组成类型，体现了Java平台的设计者对不同异常情况的分类。
Exception:
Exception是程序正常运行中，可以预料的意外情况，可能并且应该被捕获，进行相应的处理
Exception又分为可检查(checked)异常和不检查(unchecked)异常,可检查异常在源代码中必须显式的进行捕获处理这是编译期检查的一部分。不检查异常就是所谓的运行时异常，类似NullPointerException、ArrayIndexOutOfBoundsException之类，通常是可以编码避免的逻辑错误，具体根据要求来进行判断是否需要捕获，并不会在编译期强制要求
Error:
Error是指正常情况下，不太可能出现的情况，绝大多数的Error都会导致程序(比如JVM自身)处于非正常情况，所以不便于也不需要捕获，常见的如OutOfMemory之类的，都是Error的子类
Java异常处理
对于这些Exception、Error，java有自己的一套处理方法，即是使用try-catch-finally块，throw、throws关键字但是同时也要注意使用的场景。
try-catch-finally
在java 7之前都是使用这种方式来关闭资源，，这种异常处理代码比较繁琐，随着Java语言的发展，引入了一些更加便利的特性，比如try-with-resources、multiple catch,在编译时期，会自动生成相应的处理逻辑，比如，自动按照约定俗成close那些扩展了AutoCloseable或者Closeable对象
try(BufferReader br = new BufferReader(...);
BufferWriter writer = new BufferWriter(...)) {//Try-with-resources
//do something
} catch(IOException | XEception e){ //Multiple catch
//Handle it
}throw、throws
- throw关键字通常用在方法体中，并且抛出一个异常对象。程序在执行到throw语句时立即停止，它后面的语句都不执行
- throws : 通常被应用在声明方法时，用来指定可能抛出的异常。多个异常可以使用逗号隔开。当在主函数中调用该方法时，如果发生异常，就会将异常抛给指定异常对象
- 通过throw抛出异常后，如果想在上一级代码中来捕获并处理异常，则需要在抛出异常的方法中使用throws关键字在方法声明中指明要抛出的异常；如果要捕捉throw抛出的异常，则必须使用try—catch语句
- throws表示出现异常的一种可能性，并不一定会发生这些异常；throw则是抛出了异常，执行throw则一定抛出了某种异常
void methodTest(int a) throws Exception1,Exception3{
try{
......
}catch(Exception1 e){
throw e;
}catch(Exception2 e){
//此异常自己处理，不必抛出
System.out.println("出错了！");
}
if(a!=b)
throw new Exception3("自定义异常");
} 异常处理合理性分析
捕获特定异常
在程序中尽量不要捕获类似Exception这样的通用异常，而应该是捕获特定的异常，因为在日常的开发中，通常是由多个人同时协作，让自己的代码能直观的体现更过的信息是很必要的，而泛泛的Exception之类，恰恰的隐藏了我们的目的，同时也要保证程序不会捕获我们不希望捕获的异常，比如RuntimeException,我们可能更希望被散出来而不是被捕获
try{
//业务代码
Thread.sleep(1000L);
} catch(Exception e) {
//Ignore it
}尽量不要捕获Throwable或者Error
这样很难保证我们能够正确的处理OutOfMemoryError
尽量不使用printStackTrace()输出信息
/**
这段代码作为实验代码是没有什么问题的，但是在产品代码中，通常是不允许这么处理的，因为在稍
微复杂一点的生产系统中，标准出错不是一个合适的输出选项，因为很难判断到底是输出到哪里了，
所以最好是使用产品日志详细的输出到日志系统中
*/
try{
//业务逻辑
} catch(IOException e) {
e.printStackTrace();
}Java异常处理机制的性能角度分析
Java异常处理机制中有两处比较昂贵的地方：
- try-catch代码段会产生额外的性能开销，或者换个角度来说，它往往会影响JVM对代码的优化，所以建议仅捕获有必要代码段，不要用一个大的try包住整段的代码，同时利用异常控制代码流程，也不是一个好的方法，远比我们通常意义上的条件语句要低效。
- Java每实例化一个Exception,都会对当前的栈进行快照，这是一个相对比较重的操作，如果发生的频繁，这个开销就不能忽略了，所以对于部分追求性能的底层类库，有种方式是创建不进行栈快照的Exception
Exception、Error一些子类对比
NoClassDefFoundError是一个错误(Error)，而ClassNOtFoundException是一个异常，我们可以从异常中恢复程序但却不应该尝试从错误中恢复程序
ClassNotFoundException的产生原因：
Java支持使用Class.forName方法来动态地加载类，任意一个类的类名如果被作为参数传递给这个方法都将导致该类被加载到JVM内存中，如果这个类在类路径中没有被找到，那么此时就会在运行时抛出ClassNotFoundException异常。
要解决这个问题很容易，唯一需要做的就是要确保所需的类连同它依赖的包存在于类路径中。当Class.forName被调用的时候，类加载器会查找类路径中的类，如果找到了那么这个类就会被成功加载，如果没找到，那么就会抛出ClassNotFountException，除了Class.forName，ClassLoader.loadClass、ClassLOader.findSystemClass在动态加载类到内存中的时候也可能会抛出这个异常。
另外还有一个导致ClassNotFoundException的原因就是：当一个类已经某个类加载器加载到内存中了，此时另一个类加载器又尝试着动态地从同一个包中加载这个类。
由于类的动态加载在某种程度上是被开发者所控制的，所以他可以选择catch这个异常然后采取相应的补救措施。有些程序可能希望忽略这个异常而采取其他方法。还有一些程序则会终止程序然后让用户再次尝试前做点事情
NoClassDefFoundError产生的原因：
如果JVM或者ClassLoader实例尝试加载（可以通过正常的方法调用，也可能是使用new来创建新的对象）类的时候却找不到类的定义。要查找的类在编译的时候是存在的，运行的时候却找不到了。这个错误往往是你使用new操作符来创建一个新的对象但却找不到该对象对应的类。这个时候就会导致NoClassDefFoundError，由于NoClassDefFoundError是有JVM引起的，所以不应该尝试捕捉这个错误。
解决这个问题的办法就是：查找那些在开发期间存在于类路径下但在运行期间却不在类路径下的类。
ClassNotFoundException发生在装入阶段。当应用程序试图通过类的字符串名称，使用常规的三种方法装入类，但却找不到指定名称的类定义时就抛出该异常。也就是说你如果编译了一个类B，在类A中调用，编译完成以后，你又删除掉B，运行A的时候那么就会出现这个错误
加载时从外存储器找不到需要的class就出现ClassNotFoundException ，连接时从内存找不到需要的class就出现NoClassDefFoundError