Java中的异常处理机制综合

异常的处理机制有两种模型：Java和C++都采用的“错误中止模型”，即一旦错误发生，则无法回到原地继续执行；还有一种是“错误回复模型”，试图更正当前错误，让程序能在异常处理后继续在该店进行运行，这种机制类似方法的调用。

有的高级语言是让函数的使用者去关注函数可能会出现的的异常情况，而Java是将这件事交给方法的设计者去做，即将方法运行时可能会出现的异常全部预先定义好，并且让这些异常类独立于它具体服务的方法而组织成一个类树。并且，Java中必须对可能发生的异常进行处理，否则JVM不会让你编译通过。同时，Java的异常处理机制将“异常处理”的职能和方法本身的职能通过两个不同的出口分离开来。

Java异常类的结构如下：

Throwable类 <- Error类

<- Exception类 <- RuntimeExceotion(运行时异常类) <- 若干子类

<- 直接继承Excetion类的异常类(如NullPointException...等等)

其中Error类是指系统错误和编译时异常，我们不应该去试图捕获它；

RuntimeException属于non-check异常(未检查异常)，Java认为是程序设计时的错误，不需要做异常说明，JVM也不会去捕获它；

直接继承Exception类的异常属于已检查异常，它们才是编程时我们需要真正关心的。对于这种异常，我们有两种处理方法：

1）将含有“异常”出口的方法放入try/catch中；

2）不直接监听捕捉被“引用”方法的异常，而是将异常关联传递给引用方法，同时监听捕捉工作也相应向上传递；

注意：

1、异常最终必须在catch块中被处理而“中止”其生命，或者抛到main()方法后继续抛给JVM，由JVM处理，打印出堆栈中的错误信息，来“结束”异常的生命，否则是无法通过编译的。

2、使用throws关键字进行异常的说明，但是异常的说明并不属于方法原型的一部分，因此也就不能因为异常说明的不同而实现方法的重载。

3、finally子句一般用在try/catch块之后，用来做资源的释放，不管是否发生异常它都会执行。但是它有

一个缺陷，即finally中可以抛出异常而取代try块中抛出的异常，而造成异常的丢失，try块后面没有catch块会出现编译错误，但是try块后面只哟finally子句是可以通过编译的！

4、父类的public方法中定义的异常不能在子类中被扩大，即子类该方法中定义的异常类型应该是父类中定义异常的子类；但是如果是在构造函数中，情况则不同，因为父类的构造函数总会在子类中得到调用，因此子类构造函数中定义的异常应该包含父类中定义的异常，但同时子类是不能捕获父类的构造函数中的异常的。

5、异常匹配时，应该把比较靠下的异常类型放在catch子句比较靠前的位置，否则它会被靠前的父类对象所覆盖。

6、如果不想处理异常，有两种解决方法(当然这种动机值得商榷)：

1）在main()方法中定义抛出异常，直接交给JVM去处理；

2）把“已检查异常”转换成“未检查异常”，即使用RuntimeException类包装前面抛出的异常，然后再将RuntimeException异常抛出。

参考：http://tech.ccidnet.com/art/3539/20071102/1262637_1.html

http://blog.csdn.net/liking100/archive/2006/06/09/784699.aspx