Checked exception、Unchecked exception、Error

转载：http://dev.csdn.net/htmls/82/82479.html

1、任何的异常都是Throwable类，并且在它之下包含两个字类Error和Exception。RuntimeException是Exception的子类。

2、 除了Error与RuntimeException，其他剩下的异常都是你需要关心的，而这些异常类统称为Checked Exception,至于Error与RuntimeException则被统称为Unchecked Exception。

3、Error:Error仅在当在Java虚拟机中发生动态连接失败或其它的定位失败的时候，Java虚拟机抛出一个Error对象。

4、Checked exception:这类异常都是Exception的子类 。异常的向上抛出机制进行处理，如果子类可能产生A异常，那么在父类中也必须throws A异常。可能导致的问题：代码效率低，耦合度过高。(SQLException)

5、Unchecked exception:  这类异常都是RuntimeException的子类，虽然RuntimeException同样也是Exception的子类，但是它们是特殊的，它们不能通过client code来试图解决，所以称为Unchecked exception。（NullPointerException）

6、当程序执行过程中，遇到uncheck exception，则程序中止，不再执行之后的代码。

 

 

public class TestException {
	public static void main(String[] args){
		//当程序执行过程中，遇到uncheck exception，则程序中止，不再执行之后的代码。
		test1(); 
		test2();  
		
	    try {
			test3();
		} catch (MyException e) {
			throw new RuntimeException(e);
		}
	}
	
	//方法内部抛出的异常,必须处理,要么try catch要么throw
	public static  void test1(){
		System.out.println("invoke test1");
		throw new IllegalArgumentException();  
	}
	//uncheck exception,调用时候不需要捕获
	public static  void test2() throws IllegalArgumentException{
		System.out.println("invoke test2");
	}
	//check exception,调用的时候必须捕获
	public static  void test3() throws MyException{
		System.out.println("invoke test3");
	}
}

 public class MyException extends Exception{
	public MyException() {
		super();
	}
}

   

 

关于怎么使用异常，有以下两个观点。

观点一：

 在使用UseCase来描述一个场景的时候，有一个主事件流和n个异常流。异常流可能发生在主事件流的过程，而try语句里面实现的是主事件流，而catch里面实现的是异常流，在这里Exception不代表程序出现了异常或者错误，Exception只是面向对象化的业务逻辑控制方法。如果没有明白这一点，那么我认为并没有真正明白应该怎么使用Java来正确的编程。 

      而我自己写的程序，会自定义大量的Exception类，所有这些Exception类都不意味着程序出现了异常或者错误，只是代表非主事件流的发生的，用来进行那些分支流程的流程控制的。例如你往权限系统中增加一个用户，应该定义1个异常类，UserExistedException，抛出这个异常不代表你插入动作失败，只说明你碰到一个分支流程，留待后面的catch中来处理这个分支流程。传统的程序员会写一个if else来处理，而一个合格的OOP程序员应该有意识的使用try catch 方式来区分主事件流和n个分支流程的处理，通过try catch，而不是if else来从代码上把不同的事件流隔离开来进行分别的代码撰写。

 

观点二：

1、什么时候抛出异常--涉及到服务类 

2、抛出checked还是unchecked的异常--涉及到客户类 

 对第一个问题来，异常就是我们认为在正常情况下不可能发生的问题，并且服务代码不知道如何去处理。如Hibernate里面的LoadObject使用没有发现这个对象存在，那Hibernate也是认为不可能的，除非其他代码直接删除了数据库里面的记录，那么也需要抛出异常。当然Hibernate本身也不知道如何处理这种情况。

 

但是如果发生的情况是可以预期的，那我不认为应该抛出例外。象上面这个userExist的情况，我认为应该在前面已经分流，应该首先判断这个用户是否存在，if(userExists())，然后进行处理，而不应当抛出例外。以及login应当返回true或者false。也就是说，这些属于程序的正常流程，而不是例外，不是异常。把例外作为正常程序流程的控制机制，只不过是把服务代码中的if转移到客户代码去，没有减少任何需要处理的代码，反而增加了系统的负担（生成例外栈）。 

       还有抛出异常的情况是违反方法的先决条件，每一个方法都有自己的先决条件和后置条件，方法只有在正确的前提下才能执行达到一个正确的后果，（所谓类的不变量）。譬如你去存取一个数组的某一个元素，这个存取方法有一个前提条件，就是你的索引应当落入它的最大下标和最小下标之间，不然就应当抛出一个例外。

  对于第二个问题，端视于客户代码是否能够根据这个例外进行合理的处理。如果客户代码根本就不知道如何处理这个例外，应当把它作为一个unchecked例外，例如上面下标的问题，客户代码用一个不合法的下标来存取数组，那么抛出一个checked例外以后，客户代码是+1还是-1？显然根本就不可能做出“合理的”处理，客户既然不能处理，还要强制它去处理，那么就是捕获，打印了事，没有增加任何价值。但是如果是客户可以处理的，或者可以选择不同的方式处理的，那么就可能需要用checked，但我发现很少有这样的情况。对于类似于RemoteException或者SQLException这些Exception,我一般都转换为具体的业务Exception，而我所有的业务Exception都是RuntimeException. 

         所以我的观点是，是否抛出例外就是服务代码是否进行合理的处理，抛出什么类型的例外就是客户代码是否能够合理的处理。

保护封装性的代码实例：

      不要让你要抛出的checked exception升级到较高的层次。例如，不要让SQLException延伸到业务层。业务层并不需要（不关心？）SQLException。你有两种方法来解决这种问题：

 1）转变SQLException为另外一个checked exception，如果客户端并不需要恢复这种异常的话；
 2）转变SQLException为一个unchecked exception，如果客户端对这种异常无能为力的话；

      多数情况下，客户端代码都是对SQLException无能为力的，因此你要毫不犹豫的把它转变为一个unchecked exception，看看下边的代码：

public void dataAccessCode(){ 
try{ 
      .  .some code that throws SQLException 
}catch(SQLException ex){ 
     ex.printStacktrace(); 
} 
}

       上边的catch块紧紧打印异常信息而没有任何的直接操作，这是情有可原的，因为对于SQLException你还奢望客户端做些什么呢？（但是显然这种就象什么事情都没发生一样的做法是不可取的）那么有没有另外一种更加可行的方法呢？ 看下面代码：
public void dataAccessCode(){ 
try{ 
     ..some code that throws SQLException 
}catch(SQLException ex){ 
    throw new RuntimeException(ex); 
} 
} 
     上边的做法是把SQLException转换为RuntimeException，一旦SQLException被抛出，那么程序将抛出RuntimeException,此时程序被挂起并返回客户端异常信息。 调用该方法的程序代码中也不用再捕获SQLException异常：

public void do(){

     dataAccessCode();    
}