异常处理，一次捕获全部异常缺点， 整块代码异常抓取的缺点
1、java.lang.NullPointerException(空指针异常)
调用了未经初始化的对象或者是不存在的对象
经常出现在创建图片，调用数组这些操作中，比如图片未经初始化，或者图片创建时的路径错误等等。对数组操作中出现空指针，
即把数组的初始化和数组元素的初始化混淆起来了。数组的初始化是对数组分配需要的空间，而初始化后的数组，其中的元素并没有实例化，
依然是空的，所以还需要对每个元素都进行初始化（如果要调用的话）。
2、 java.lang.ClassNotFoundException
指定的类不存在
这里主要考虑一下类的名称和路径是否正确即可，通常都是程序试图通过字符串来加载某个类时可能引发 异常
比如：调用Class.forName();
或者调用ClassLoad的finaSystemClass();或者LoadClass();
- 1
- 2
- 1
- 2
3、 java.lang.NumberFormatException
字符串转换为数字异常
当试图将一个String转换为指定的数字类型，而该字符串确不满足数字类型要求的格式时，抛出该异常.如现在讲字符型的数据“123456”转换为数值型数据时，是允许的。
但是如果字符型数据中包含了非数字型的字符，如123#56，此时转换为数值型时就会出现异常。系统就会捕捉到这个异常，并进行处理.
4、java.lang.IndexOutOfBoundsException
数组下标越界异常
查看调用的数组或者字符串的下标值是不是超出了数组的范围，一般来说，显示（即直接用常数当下标）调用不太容易出这样的错，但隐式（即用变量表示下标）调用就经常出错了，还有一种情况，是程序中定义的数组的长度是通过某些特定方法决定的，不是事先声明的，这个时候，最好先查看一下数组的length，以免出现这个异常。
5、java.lang.IllegalArgumentException
方法的参数错误
比如g.setColor(int red,int green,int blue)这个方法中的三个值，如果有超过２５５的也会出现这个异常，因此一旦发现这个异常，我们要做的，就是赶紧去检查一下方法调用中的参数传递是不是出现了错误。
6、java.lang.IllegalAccessException
没有访问权限
当应用程序要调用一个类，但当前的方法即没有对该类的访问权限便会出现这个异常。对程序中用了Package的情况下要注意这个异常
7、java.lang.ArithmeticException
数学运算异常
当算术运算中出现了除以零这样的运算就会出这样的异常。
8、java.lang.ClassCastException
数据类型转换异常
当试图将对某个对象强制执行向下转型，但该对象又不可转换又不可转换为其子类的实例时将引发该异常，如下列代码。
-
Object obj = new Integer(0); -
String str = obj;
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
9、 java.lang.FileNotFoundException
文件未找到异常
当程序试图打开一个不存在的文件进行读写时将会引发该异常。该异常由FileInputStream,FileOutputStream,RandomAccessFile的构造器声明抛出
即使被操作的文件存在，但是由于某些原因不可访问，比如打开一个只读文件进行写入，这些构造方法仍然会引发异常
10、java.lang.ArrayStoreException
数组存储异常
当试图将类型不兼容类型的对象存入一个Object[]数组时将引发异常
-
Object[] obj = new String[3]; -
obj[0] = new Integer(0);
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
11、java.lang.NoSuchMethodException
方法不存在异常
当程序试图通过反射来创建对象，访问(修改或读取)某个方法，但是该方法不存在就会引发异常
12、 java.lang.NoSuchFiledException
方法不存在异常
当程序试图通过反射来创建对象，访问(修改或读取)某个filed，但是该filed不存在就会引发异常
13、 java.lang.EOFException
文件已结束异常
当程序在输入的过程中遇到文件或流的结尾时，引发异常。因此该异常用于检查是否达到文件或流的结尾
14、java.lang.InstantiationException
实例化异常
当试图通过Class的newInstance()方法创建某个类的实例,但程序无法通过该构造器来创建该对象时引发
Class对象表示一个抽象类，接口，数组类，基本类型
该Class表示的类没有对应的构造器
15、java.lang.InterruptedException
被中止异常
当某个线程处于长时间的等待、休眠或其他暂停状态，而此时其他的线程通过Thread的interrupt方法终止该线程时抛出该异常。
16、java.lang.CloneNotSupportedException
不支持克隆异常
当没有实现Cloneable接口或者不支持克隆方法时,调用其clone()方法则抛出该异常。
17、java.lang.OutOfMemoryException
内存不足错误
当可用内存不足以让Java虚拟机分配给一个对象时抛出该错误。
18、java.lang.NoClassDefFoundException
未找到类定义错误
当Java虚拟机或者类装载器试图实例化某个类，而找不到该类的定义时抛出该错误。
违背安全原则异常：SecturityException
操作数据库异常：SQLException
输入输出异常：IOException
通信异常：SocketException
1 引言-异常处理
在JAVA语言出现以前，传统的异常处理方式多采用返回值来标识程序出现的异常情况，这种方式虽然为程序员所熟悉，但却有多个坏处。
首先，一个API可以返回任意的返回值，而这些返回值本身并不能解释该返回值是否代表一个异常情况发生了和该异常的具体情况，需要调用API的程序自己判断并解释返回值的含义。
其次，并没有一种机制来保证异常情况一定会得到处理，调用程序可以简单的忽略该返回值，需要调用API的程序员记住去检测返回值并处理异常情况。这种方式还让程序代码变得晦涩冗长，当进行IO操作等容易出现异常情况的处理时，你会发现代码的很大部分用于处理异常情况的switch分支，程序代码的可读性变得很差。
上面提到的问题，JAVA的异常处理机制提供了很好的解决方案。通过抛出JDK预定义或者自定义的异常,能够表明程序中出现了什么样的异常情况；而且JAVA的语言机制保证了异常一定会得到恰当的处理；合理的使用异常处理机制，会让程序代码清晰易懂。
2 JAVA异常的处理机制
当程序中抛出一个异常后，程序从程序中导致异常的代码处跳出，java虚拟机检测寻找和try关键字匹配的处理该异常的catch块，如果找到，将控制权交到catch块中的代码，然后继续往下执行程序，try块中发生异常的代码不会被重新执行。如果没有找到处理该异常的catch块，在所有的finally块代码被执行和当前线程的所属的ThreadGroup的uncaughtException方法被调用后，遇到异常的当前线程被中止。
3 JAVA异常的类层次
1 JAVA异常的类层次
Throwable是所有异常的基类，程序中一般不会直接抛出Throwable对象，Exception和Error是Throwable的子类，Exception下面又有RuntimeException和一般的Exception两类。可以把JAVA异常分为三类：
第一类是Error，Error表示程序在运行期间出现了十分严重、不可恢复的错误，在这种情况下应用程序只能中止运行，例如JAVA 虚拟机出现错误。Error是一种unchecked Exception,编译器不会检查Error是否被处理,在程序中不用捕获Error类型的异常；一般情况下，在程序中也不应该抛出Error类型的异常。
第二类是RuntimeException, RuntimeException 是一种unchecked Exception，即表示编译器不会检查程序是否对RuntimeException作了处理，在程序中不必捕获RuntimException类型的异常，也不必在方法体声明抛出RuntimeException类。RuntimeException发生的时候，表示程序中出现了编程错误，所以应该找出错误修改程序，而不是去捕获RuntimeException。
第三类是一般的checked Exception,这也是在编程中使用最多的Exception,所有继承自Exception并且不是RuntimeException的异常都是checked Exception，如图1中的IOException和ClassNotFoundException。JAVA 语言规定必须对checked Exception作处理，编译器会对此作检查，要么在方法体中声明抛出checked Exception,要么使用catch语句捕获checked Exception进行处理，不然不能通过编译。checked Exception用于以下的语义环境：
（1） 该异常发生后是可以被恢复的，如一个Internet连接发生异常被中止后，可以重新连接再进行后续操作。
（2） 程序依赖于不可靠的外部条件，该依赖条件可能出错，如系统IO。
（3） 该异常发生后并不会导致程序处理错误，进行一些处理后可以继续后续操作。
4 JAVA异常处理中的注意事项
合理使用JAVA异常机制可以使程序健壮而清晰，但不幸的是，JAVA异常处理机制常常被错误的使用，下面就是一些关于Exception的注意事项：
1． 不要忽略checked Exception
请看下面的代码：
try
{
method1(); //method1抛出ExceptionA
}
catch(ExceptionA e)
{
e.printStackTrace();
}
上面的代码似乎没有什么问题，捕获异常后将异常打印，然后继续执行。事实上在catch块中对发生的异常情况并没有作任何处理(打印异常不能是算是处理异常，因为在程序交付运行后调试信息就没有什么用处了)。这样程序虽然能够继续执行，但是由于这里的操作已经发生异常，将会导致以后的操作并不能按照预期的情况发展下去，可能导致两个结果：
一是由于这里的异常导致在程序中别的地方抛出一个异常，这种情况会使程序员在调试时感到迷惑，因为新的异常抛出的地方并不是程序真正发生问题的地方，也不是发生问题的真正原因；
另外一个是程序继续运行，并得出一个错误的输出结果，这种问题更加难以捕捉，因为很可能把它当成一个正确的输出。
那么应该如何处理呢，这里有四个选择：
（1） 处理异常，进行修复以让程序继续执行。
（2） 重新抛出异常，在对异常进行分析后发现这里不能处理它，那么重新抛出异常，让调用者处理。
（3） 将异常转换为用户可以理解的自定义异常再抛出，这时应该注意不要丢失原始异常信息（见5）。
（4） 不要捕获异常。
因此，当捕获一个unchecked Exception的时候，必须对异常进行处理；如果认为不必要在这里作处理，就不要捕获该异常，在方法体中声明方法抛出异常，由上层调用者来处理该异常。
2． 不要一次捕获所有的异常
请看下面的代码：
try
{
method1(); //method1抛出ExceptionA
method2(); //method1抛出ExceptionB
method3(); //method1抛出ExceptionC
}
catch(Exception e)
{
……
}
这是一个很诱人的方案，代码中使用一个catch子句捕获了所有异常，看上去完美而且简洁，事实上很多代码也是这样写的。但这里有两个潜在的缺陷，一是针对try块中抛出的每种Exception，很可能需要不同的处理和恢复措施，而由于这里只有一个catch块，分别处理就不能实现。二是try块中还可能抛出RuntimeException,代码中捕获了所有可能抛出的RuntimeException而没有作任何处理，掩盖了编程的错误，会导致程序难以调试。
下面是改正后的正确代码：
try
{
method1(); //method1抛出ExceptionA
method2(); //method1抛出ExceptionB
method3(); //method1抛出ExceptionC
}
catch(ExceptionA e)
{
……
}
catch(ExceptionB e)
{
……
}
catch(ExceptionC e)
{
……
}
3． 使用finally块释放资源
finally关键字保证无论程序使用任何方式离开try块，finally中的语句都会被执行。在以下三种情况下会进入finally块：
（1） try块中的代码正常执行完毕。
（2） 在try块中抛出异常。
（3） 在try块中执行return、break、continue。
因此，当你需要一个地方来执行在任何情况下都必须执行的代码时，就可以将这些
代码放入finally块中。当你的程序中使用了外界资源,如数据库连接，文件等，必须将释放这些资源的代码写入finally块中。
必须注意的是，在finally块中不能抛出异常。JAVA异常处理机制保证无论在任何情况下必须先执行finally块然后在离开try块，因此在try块中发生异常的时候，JAVA虚拟机先转到finally块执行finally块中的代码，finally块执行完毕后，再向外抛出异常。如果在finally块中抛出异常，try块捕捉的异常就不能抛出，外部捕捉到的异常就是finally块中的异常信息，而try块中发生的真正的异常堆栈信息则丢失了。
请看下面的代码：
Connection con = null;
try
{
con = dataSource.getConnection();
……
}
catch(SQLException e)
{
……
throw e;//进行一些处理后再将数据库异常抛出给调用者处理
}
finally
{
try
{
con.close();
}
catch(SQLException e)
{
e.printStackTrace();
……
}
}
运行程序后，调用者得到的信息如下
java.lang.NullPointerException
at myPackage.MyClass.method1(methodl.java:266)
而不是我们期望得到的数据库异常。这是因为这里的con是null的关系，在finally语句中抛出了NullPointerException,在finally块中增加对con是否为null的判断可以避免产生这种情况。
4． 异常不能影响对象的状态
异常产生后不能影响对象的状态，这是异常处理中的一条重要规则。 在一个函数
中发生异常后，对象的状态应该和调用这个函数之前保持一致，以确保对象处于正确的状态中。
如果对象是不可变对象(不可变对象指调用构造函数创建后就不能改变的对象，即
创建后没有任何方法可以改变对象的状态)，那么异常发生后对象状态肯定不会改变。如果是可变对象，必须在编程中注意保证异常不会影响对象状态。有三个方法可以达到这个目的：
（1） 将可能产生异常的代码和改变对象状态的代码分开，先执行可能产生异常的代码，如果产生异常，就不执行改变对象状态的代码。
（2） 对不容易分离产生异常代码和改变对象状态代码的方法，定义一个recover方法，在异常产生后调用recover方法修复被改变的类变量，恢复方法调用前的类状态。
（3） 在方法中使用对象的拷贝，这样当异常发生后，被影响的只是拷贝，对象本身不会受到影响。
5． 丢失的异常
请看下面的代码：
public void method2()
{
try
{
……
method1(); //method1进行了数据库操作
}
catch(SQLException e)
{
……
throw new MyException(“发生了数据库异常:”+e.getMessage);
}
}
public void method3()
{
try
{
method2();
}
catch(MyException e)
{
e.printStackTrace();
……
}
}
上面method2的代码中，try块捕获method1抛出的数据库异常SQLException后，抛出了新的自定义异常MyException。这段代码是否并没有什么问题，但看一下控制台的输出：
MyException:发生了数据库异常：对象名称 'MyTable' 无效。
at MyClass.method2(MyClass.java:232)
at MyClass.method3(MyClass.java:255)
原始异常SQLException的信息丢失了，这里只能看到method2里面定义的MyException的堆栈情况；而method1中发生的数据库异常的堆栈则看不到，如何排错呢，只有在method1的代码行中一行行去寻找数据库操作语句了，祈祷method1的方法体短一些吧。
JDK的开发者们也意识到了这个情况，在JDK1.4.1中，Throwable类增加了两个构造方法,public Throwable(Throwable cause)和public Throwable(String message,Throwable cause)，在构造函数中传入的原始异常堆栈信息将会在printStackTrace方法中打印出来。但对于还在使用JDK1.3的程序员，就只能自己实现打印原始异常堆栈信息的功能了。实现过程也很简单，只需要在自定义的异常类中增加一个原始异常字段，在构造函数中传入原始异常，然后重载printStackTrace方法，首先调用类中保存的原始异常的printStackTrace方法，然后再调用super.printStackTrace方法就可以打印出原始异常信息了。可以这样定义前面代码中出现的MyException类：
public class MyExceptionextends Exception
{
//构造函数
public SMException(Throwable cause)
{
this.cause_ = cause;
}
public MyException(String s,Throwable cause)
{
super(s);
this.cause_ = cause;
}
//重载printStackTrace方法，打印出原始异常堆栈信息
public void printStackTrace()
{
if (cause_ != null)
{
cause_.printStackTrace();
}
super.printStackTrace(s);
}
public void printStackTrace(PrintStream s)
{
if (cause_ != null)
{
cause_.printStackTrace(s);
}
super.printStackTrace(s);
}
public void printStackTrace(PrintWriter s)
{
if (cause_ != null)
{
cause_.printStackTrace(s);
}
super.printStackTrace(s);
}
//原始异常
private Throwable cause_;
}
6． 不要使用同时使用异常机制和返回值来进行异常处理
下面是我们项目中的一段代码
try
{
doSomething();
}
catch(MyException e)
{
if(e.getErrcode == -1)
{
……
}
if(e.getErrcode == -2)
{
……
}
……
}
假如在过一段时间后来看这段代码，你能弄明白是什么意思吗？混合使用JAVA异常处理机制和返回值使程序的异常处理部分变得“丑陋不堪”，并难以理解。如果有多种不同的异常情况，就定义多种不同的异常，而不要像上面代码那样综合使用Exception和返回值。
修改后的正确代码如下：
try
{
doSomething(); //抛出MyExceptionA和MyExceptionB
}
catch(MyExceptionA e)
{
……
}
catch(MyExceptionB e)
{
……
}
7． 不要让try块过于庞大
出于省事的目的，很多人习惯于用一个庞大的try块包含所有可能产生异常的代码，
这样有两个坏处：
阅读代码的时候，在try块冗长的代码中，不容易知道到底是哪些代码会抛出哪些异常，不利于代码维护。
使用try捕获异常是以程序执行效率为代价的，将不需要捕获异常的代码包含在try块中，影响了代码执行的效率。