随笔-204  评论-149  文章-0  trackbacks-0

Java 提供了两种Exception 的模式,一种是执行的时候所产生的Exception (Runtime Exception),另外一种则是受控制的Exception (Checked Exception)。

所有的Checked Exception 均从java.lang.Exception 继承而来,而Runtime Exception 则继承java.lang.RuntimeException 或java.lang.Error (实际上java.lang.RuntimeException 的上一层也是java.lang.Exception,这说明作为exception两者并没有本质的区别,只是java语言本身从功能考虑有所区分,这才导致下面提到的不同点)。

一个函数如果会抛出Checked Exception ,(这里包含两种情况,一个是函数本身抛出,另外一种是它调用的函数会抛出Checked Exception 但是它并没有去catch这个exception),那在声明此函数的时候必须标明throws XXXException()。而Runtime Exception不需要如此声明。

逻辑上看,Runtime Exception 与Checked Exception 使用目的不一样。一般而言,Checked Exception 表示这个Exception 必须要被处理,也就是说程序设计者应该已经知道可能会收到某个Exception(因为要try catch住) ,所以程序设计者应该能也必须(或者标明throws XXXException()继续抛出去,或者try catch处理,不然是编译不过的)针对这些不同的Checked Exception 做出不同的处理。而Runtime Exception 通常会暗示着程序上的错误,这种错误会导致程序设计者无法处理,而造成程序无法继续执行下去(可以try catch处理而避免程序挂掉,但是这常常会掩盖问题所在)。


checked exception由于必须被处理,会给程序员带来额外的麻烦,试想一个函数a,它会调用到b1,b2...,b9一共9个函数,这些函数每个都会抛出checked exception,而a函数里面又没有办法处理这些exception,那在声明a函数的时候就必须连写9个throw xxxException,够累的!!然而这仅仅是问题的一个方面,所以下面这篇文章试图说服我们尽量使用runtime exception替代checked exception(前面提到可以try catch处理runtime exception,而避免程序挂掉,这也是这样做的一个前提)。

这篇文章指出了Java中checked Exception的一些缺点,提出应该在程序设计中避免使用checked Exception,对于需要处理checked Exception的代码,可以使用ExceptionAdapter这个类对checked Exception进行包装。这篇文章的概念和ExceptionAdapter这个类均源自Bruce Eckel的Does Java need Checked Exception。


Java
Exception分为两类,一类是RuntimeException及其子类,另外一类就是checked ExceptionJava要求函数对没有被catch处理掉的checked Exception,需要将其写在函数的声明部分。然而,这一要求常常给程序员带来一些不必要的负担。

为了避免在函数声明中写throws部分,在Java项目里面常常可以看到以下代码用来‘吞掉’Exception

 try {
  
// 
 }
 catch (Exception ex) {
           ex.printStackTrace();
  }


这显然不是一个好的处理Exception办法,事实上,catch并处理一个Exception意味着让程序从发生的错误(Exception)中恢复过来。从这种意义上说,已上的代码只可能在一些很简单的情况下工作而不带来问题。

对于很多Exception,往往没有去处理它并让程序从错误中恢复出来的办法,这时唯一能做的事情可能就是在界面上显示一些提示信息给用户。这种情况下让程序抛出遇到的Exception是更为合理的做法。然而,这样做会使得一些函数的声明急剧膨胀。一个函数可能需要声明会抛出的78checked Exception,而且每个调用它的函数也需要同样的声明。

比这更糟糕的是,这有可能破坏类设计的open-close原则。简单来说,open-close原则是指当扩展一个模块的时候,可以不影响其现有的clientopen-close原则是通过继承来实现的,当继承一个类的时候,我们既扩展了这个类,也不会影响原有的client(因为对这个类没有改动)。

现在考虑下面这种情况,有一个父类Base

 

public class Base {
    
public void foo() throws ExceptionA {
       
// 
    }

}

 

 

现在需要继承Base这个类并重载foo这个方法,在新的实现中,foo可能抛出ExceptionB

public class Extend extends Base {
    
public void foo() throws ExceptionB {
       
// 
    }

}

 


然而,这样写在Java里面是不合法的,尽管Java不会抛出的Exception看作函数特征的一部分,但子类声明抛出的Exception必须是父类的子集。
可以在Base类的foo方法中加入抛出ExceptionB的声明,然而,这样就破坏了open-close原则。而且,有时我们没有办法去修改父类,比如当重载一个Jdk里的类的时候。

另一个可能的做法是在Extendfoo方法中catchExceptionB,然后构造一个ExceptionA并抛出。这是个可行的办法但也只是一个权宜之计。

如果使用RuntimeException,这些问题都不会存在。这说明checked Exception并不是一个很实用的概念,也意味着在程序设计的时候,我们应该让自己的Exception类继承RuntimeException而不是Exception。(这和JDK的建议正好相反,但实践证明这样做代码的质量更好。)

对于那些需要处理checked Exception的代码,可以利用一个ExceptionAdapter的类把checked Exception包装成一个RuntimeException抛出。ExceptionAdapter来自Bruce EckelDoes Java need Checked Exception这篇文章,

public class ExceptionAdapter extends RuntimeException {

    
public ExceptionAdapter(Exception ex) {

       
super(ex);

    }


    
public void printStackTrace(java.io.PrintStream s) 

       getCause().printStackTrace(s); 

    }


    
public void printStackTrace(java.io.PrintWriter s) 
       getCause().printStackTrace(s);

    }


    
// rethrow()的作用是把被包装的Exception再次抛出。

    
public void rethrow() 
       
throws Exception
    
{
       
throw (Exception) getCause();
    }

}


posted on 2009-06-20 15:49 Frank_Fang 阅读(390) 评论(0)  编辑  收藏 所属分类: Java编程

只有注册用户登录后才能发表评论。


网站导航: