异常处理机制能让程序在异常发生时，按照代码的预先设定的异常处理逻辑，针对性地处理异常，让程序尽最大可能恢复正常并继续执行，且保持代码的清晰。
Java中的异常可以是函数中的语句执行时引发的，也可以是程序员通过throw 语句手动抛出的，只要在Java程序中产生了异常，就会用一个对应类型的异常对象来封装异常，JRE就会试图寻找异常处理程序来处理异常。
Throwable类是Java异常类型的顶层父类，一个对象只有是 Throwable 类的（直接或者间接）实例，他才是一个异常对象，才能被异常处理机制识别。JDK中内建了一些常用的异常类，我们也可以自定义异常。
Throwable又派生出Error类和Exception类。
错误：Error类以及他的子类的实例，代表了JVM本身的错误。错误不能被程序员通过代码处理，Error很少出现。因此，程序员应该关注Exception为父类的分支下的各种异常类。
异常：Exception以及他的子类，代表程序运行时发送的各种不期望发生的事件。可以预料的意外情况，可能并且应该被捕获，进行相应处理，可以被Java异常处理机制使用，是异常处理的核心。
总体上我们根据Javac对异常的处理要求，将异常类分为2类：
非检查异常（unckecked exception）：Error 和 RuntimeException 以及他们的子类。javac在编译时，不会提示和发现这样的异常，不要求在程序处理这些异常。所以如果愿意，我们可以编写代码处理（使用try…catch…finally）这样的异常，也可以不处理。对于这些异常，我们应该修正代码，而不是去通过异常处理器处理 。这样的异常发生的原因多半是代码写的有问题。
检查异常（checked exception）：除了Error 和 RuntimeException的其它异常。javac强制要求程序员为这样的异常做预备处理工作（使用try…catch…finally或者throws）。在方法中要么用try-catch语句捕获它并处理，要么用throws子句声明抛出它，否则编译不会通过。这样的异常一般是由程序的运行环境导致的。因为程序可能被运行在各种未知的环境下，而程序员无法干预用户如何使用他编写的程序，于是程序员就应该为这样的异常时刻准备着。
在编写代码处理异常时，对于检查异常，有2种不同的处理方式：使用try…catch…finally语句块处理它。或者，在函数签名中使用throws 声明交给函数调用者caller去解决。
1）try…catch…finally语句块：
try
{
//try块中放可能发生异常的代码。
//如果执行完try且不发生异常，则接着去执行finally块和finally后面的代码（如果有的话）。
//如果发生异常，则尝试去匹配catch块。
}
catch (SQLException SQLexception)
{
//每一个catch块用于捕获并处理一个特定的异常，或者这异常类型的子类。Java7中可以将多个异常声明在一个catch中。
//catch后面的括号定义了异常类型和异常参数。如果异常与之匹配且是最先匹配到的，则虚拟机将使用这个catch块来处理 异常。
//在catch块中可以使用这个块的异常参数来获取异常的相关信息。异常参数是这个catch块中的局部变量，其它块不能访问。
//如果当前try块中发生的异常在后续的所有catch中都没捕获到，则先去执行finally，然后到这个函数的外部caller中去匹配异常处理器。
//如果try中没有发生异常，则所有的catch块将被忽略。
}
catch (Exception exception)
{
//...
}
finally
{
//finally块通常是可选的。
//无论异常是否发生，异常是否匹配被处理，finally都会执行。
//一个try至少要有一个catch块，否则， 至少要有1个finally块。但是finally不是用来处理异常的，finally不会捕获异常。
//finally主要做一些清理工作，如流的关闭，数据库连接的关闭等。
}
需要注意的地方
1、try块中的局部变量和catch块中的局部变量（包括异常变量），以及finally中的局部变量，他们之间不可共享使用。
2、每一个catch块用于处理一个异常。异常匹配是按照catch块的顺序从上往下寻找的，只有第一个匹配的catch会得到执行。匹配时，不仅运行精确匹配，也支持父类匹配，因此，如果同一个try块下的多个catch异常类型有父子关系，应该将子类异常放在前面，父类异常放在后面，这样保证每个catch块都有存在的意义。
3、java中，异常处理的任务就是将执行控制流从异常发生的地方转移到能够处理这种异常的地方去。也就是说：当一个函数的某条语句发生异常时，这条语句的后面的语句不会再执行，它失去了焦点。执行流跳转到最近的匹配的异常处理catch代码块去执行，异常被处理完后，执行流会接着在“处理了这个异常的catch代码块”后面接着执行。
2）throws 函数声明
throws声明：如果一个方法内部的代码会抛出检查异常（checked exception），而方法自己又没有完全处理掉，则javac保证你必须在方法的签名上使用throws关键字声明这些可能抛出的异常，否则编译不通过。
throws是另一种处理异常的方式，它不同于try…catch…finally，throws仅仅是将函数中可能出现的异常向调用者声明，而自己则不具体处理。
采取这种异常处理的原因可能是：方法本身不知道如何处理这样的异常，或者说让调用者处理更好，调用者需要为可能发生的异常负责。
public void foo() throws ExceptionType1, ExceptionType2, ExceptionTypeN
{
//foo内部可以抛出 ExceptionType1 , ExceptionType2, ExceptionTypeN 类的异常，或者他们的子类的异常对象。
}
finally块和return：
首先一个不容易理解的事实：在 try块中即便有return，break，continue等改变执行流的语句，finally也会执行。
也就是说：try…catch…finally中的return只要能执行，就都执行了，他们共同向同一个内存地址（假设地址是0×80）写入返回值，后执行的将覆盖先执行的数据，而真正被调用者取的返回值就是最后一次写入的。
根据上述推断下面结论就比较容易理解：
情况一：如果finally中有return语句，则会将try中的return语句”覆盖“掉，直接执行finally中的return语句，得到返回值，这样便无法得到try之前保留好的返回值。
情况二：如果finally中没有return语句，也没有改变要返回值，则执行完finally中的语句后，会接着执行try中的return语句，返回之前保留的值。
情况三：如果finally中没有return语句，但是改变了要返回的值，这里有点类似于引用传递和值传递的区别，分以下两种情况：
* 如果return的数据是基本数据类型，则在finally中对该基本数据的改变不起作用，try中的return语句依然会返回进入finally块之前保留的值。
* 如果return的数据是引用数据类型，而在finally中对该引用数据类型的属性值的改变起作用，try中的return语句返回的就是在finally中改变后的该属性的值。
public class ExceptionTest {
public static void main(String[] args)
{
ExceptionTest test = new ExceptionTest();
System.out.println(test.fun());
System.out.println(test.fun1());
System.out.println(test.fun2());
}
// 情况一：如果finally中有return语句，则会将try中的return语句”覆盖“掉，直接执行finally中的return语句，得到返回值，这样便无法得到try之前保留好的返回值。
public int fun()
{
int i = 10;
try
{
//doing something
return i;
}catch(Exception e){
return i;
}finally{
i = 20;
return i;
}
}
输出结果：20
// 情况二：如果finally中没有return语句，但是改变了要返回的值，这里有点类似于引用传递和值传递的区别，分以下两种情况:
// 如果return的数据是基本数据类型，则在finally中对该基本数据的改变不起作用，try中的return语句依然会返回进入finally块之前保留的值。
public int fun1()
{
int i = 10;
try
{
//doing something
return i;
}catch(Exception e){
return i;
}finally{
i = 20;
}
}
输出结果：10
// 如果return的数据是引用数据类型，而在finally中对该引用数据类型的属性值的改变起作用，try中的return语句返回的就是在finally中改变后的该属性的值。
public StringBuilder fun2()
{
StringBuilder s = new StringBuilder("Hello");
try
{
//doing something
s.append("Word");
return s;
}catch(Exception e){
return s;
}finally{
s.append("finally");
}
}
}
输出结果：HelloWordfinally
总结一下：其实return与finally并没有明显的谁强谁弱。在执行时，是return语句先把返回值写入但内存中，然后停下来等待finally语句块执行完，return再执行后面的一段。
建议：
* 不要在fianlly中使用return。
* 不要在finally中抛出异常。
* 减轻finally的任务，不要在finally中做一些其它的事情，finally块仅仅用来释放资源是最合适的。
* 尽量将所有的return写在函数的最后面，而不是try … catch … finally中。
备注：在 finally 块中抛出的任何异常都会覆盖掉在其前面由 try 或者 catch 块抛出异常。包含 return 语句的情形相似。
11条Java异常处理的最佳实践
1）不要在catch语句块中压制异常
public class ExceptionExample {
public FileInputStreamtestMethod1(){
File file = newFile("test.txt");
FileInputStreamfileInputStream = null;
try{
fileInputStream= new FileInputStream(file);
fileInputStream.read();
}catch (IOExceptione){
return null;
}
return fileInputStream;
}
public static void main(String[] args){
ExceptionExampleinstance1 = new ExceptionExample();
instance1.testMethod1();
}
}
在异常处理时进行异常压制是非常不好的编程习惯，上面的例子中，无论抛出什么异常都会被忽略，以至没有留下任何问题线索。如果在这一层次不知道如何处理异常，最好将异常重新抛出，由上层决定如何处理异常。
public class ExceptionExample {
public FileInputStreamtestMethod1() throws IOException{
File file = newFile("test.txt");
FileInputStreamfileInputStream = null;
try{
fileInputStream= new FileInputStream(file);
fileInputStream.read();
}catch (IOExceptione){
throw e;
}
returnfileInputStream;
}
public static voidmain(String[] args) throws IOException{
ExceptionExampleinstance1 = new ExceptionExample();
instance1.testMethod1();
}
}
2）要在方法定义分句中定义具体的异常
按照public FileInputStream testMethod1() throws Exception{这种写法，表示该方法会抛出所有受检查异常，这不是一个良好的编程习惯。在这种情况下，我们最好抛出足够具体的异常，以便调用者进行合适的捕获和处理，例如public FileInputStream testMethod1() throws IOException。
3）捕获具体的异常
在调用其他模块时，最好捕获由该模块抛出的具体的异常。如果某个被调用模块抛出了多个异常，那么只捕获这些异常的父类是不好的编程习惯。
例如，如果一个模块抛出FileNotFoundException和IOException，那么调用这个模块的代码最好写两个catch语句块分别捕获这两个异常，而不要只写一个捕获Exception的catch语句块。
正确的写法如下：
try {
//some statements
catch(FileNotFoundException e){
//handle here
}
catch(IOException e){
//handle here
}
你最好不要这么写：
try {
//some statements
catch(Exception e){
//handle here
}
4）记得在finally语句块中释放资源
当你在代码中建立了数据库连接、文件操作符或者其他需要被及时释放的系统资源，如果你没有及时释放这些资源，会影响到系统的性能。
为了避免这种情况发生，可以使用Java 7的try(open the resources) {deal with resources}语句，如果你还是习惯这种老式写法，则可以按照如下方式写：
finally {
try {
if (con != null) {
con.close();
}
if (stat != null) {
stat.close();
}
} catch (SQLExceptionsqlee) {
sqlee.printStackTrace();
}
}
5）异常会影响性能
异常处理的性能成本非常高，每个Java程序员在开发时都应牢记这句话。创建一个异常非常慢，抛出一个异常又会消耗1~5ms，当一个异常在应用的多个层级之间传递时，会拖累整个应用的性能。
仅在异常情况下使用异常；
在可恢复的异常情况下使用异常；
尽管使用异常有利于Java开发，但是在应用中最好不要捕获太多的调用栈，因为在很多情况下都不需要打印调用栈就知道哪里出错了。因此，异常消息应该提供恰到好处的信息。
6）使用标准异常
如果使用内建的异常可以解决问题，就不要定义自己的异常。Java API提供了上百种针对不同情况的异常类型，在开发中首先尽可能使用Java API提供的异常，如果标准的异常不能满足你的要求，这时候创建自己的定制异常。尽可能得使用标准异常有利于新加入的开发者看懂项目代码。
7）正确的包装异常类型
当需要在应用重新抛出异常时，应该正确得包装原始异常，否则会丢失原始异常，例如下面的例子中：
import java.io.IOException;
public class HelloWorld{
public static voidmain(String []args) throws Exception{
try{
throw newIOException("IOException");
}catch (IOExceptione){
throw newExampleException1("Example Exception and " + e.getMessage());
}
}
}
class ExampleException1 extends Exception{
public ExampleException1(Strings, Throwable t){
super(s,t);
}
publicExampleException1(String s){
super(s);
}
}
这个程序的输出为：
Exception in thread "main" ExampleException1: ExampleException and IOException
atHelloWorld.main(HelloWorld.java:8)
这里发现，IOException的调用栈已经丢失了，因为我们在catch语句块中没有正确包装IOException。若将catch语句块修改成下面这样，这可以发现原始异常的调用栈也被打印出来了。
catch (IOException e){
throw newExampleException1("Example Exception",e);
}
这时候的输出如下：
Exception in thread "main" ExampleException1: ExampleException
atHelloWorld.main(HelloWorld.java:8)
Caused by: java.io.IOException: IOException
atHelloWorld.main(HelloWorld.java:6)
8）避免在finally语句块中抛出异常
try {
method(); //here throws first exception
} finally {
shutdown(); //If finallyblockthrew any exception the first exception will be lost forever
}
在上面的这个代码片段中，finally代码块也可能再次抛出异常。如果同时抛出两个异常，则第一个异常的调用栈会丢失。在finally语句块中最好只做打印错误信息或者关闭资源等操作，避免在finally语句块中再次抛出异常。
9）不要使用异常控制程序的流程
不应该使用异常控制应用的执行流程，例如，本应该使用if语句进行条件判断的情况下，你却使用异常处理，这是非常不好的习惯，会严重影响应用的性能。
10）不要捕获Throwable类
在应用中不应捕获Throwable类，Error是Throwable类的子类，当应用抛出Errors的时候，一般都是不可恢复的情况。
11）为异常记录合适的文档
为应用中定义的异常定义合适的文档，如果你写了一个自定义的异常却没有文档，其他开发者会不清楚这个异常的含义，为你定义的异常配备对应的文档是一个非常好的习惯。
关于NoClassDefFoundError和ClassNotFoundException异常
java.lang.NoClassDefFoundError 和 java.lang.ClassNotFoundException 都是 Java 语言定义的标准异常。从异常类的名称看似乎都跟类的定义找不到有关，但是还是有些差异。我们先来看一下 java 规范中对这两个异常的说明：
java.lang.NoClassDefFoundError:
出现这个异常，并不是说这个.class类文件不存在，而是类加载器试图加载类的定义时却找不到这个类的定义，实际上.class文件是存在的。
java.lang.ClassNotFoundException:
从规范说明看， java.lang.ClassNotFoundException 异常抛出的根本原因是类文件找不到，缺少了.class 文件，比如少引了某个 jar，解决方法通常需要检查一下 classpath 下能不能找到包含缺失 .class 文件的 jar。
但是，很多人在碰到 java.lang.NoClassDefFoundError 异常时也会下意识的去检查是不是缺少了.class 文件，比如 SO 上的这位提问者（java.lang.NoClassDefFoundError: Couldnot initialize class XXX）-- “明明 classpath 下有那个 jar 为什么还报这个异常“。而实际上，这个异常的来源根本不是因为缺少 .class 文件。而碰到这个异常的解决办法，一般需要检查这个类定义中的初始化部分（如类属性定义、static 块等）的代码是否有抛异常的可能。
如果是 static 块，可以考虑在其中将异常捕获并打印堆栈等，或者直接在对类进行初始化调用（如 new Foobar()）时作try catch。
static{
try{
... your init code here
}catch(Throwable t){
LOG.error("Failure during static initialization", t);
}
}
