现在的位置: 首页 > 综合 > 正文

java 异常机制

2018年05月23日 ⁄ 综合 ⁄ 共 6870字 ⁄ 字号 小 中 大 ⁄ 评论关闭

Throwable 是所有 Java 程序中错误处理的父类 ，有两种资类： Error 和 Exception 。

   Error ：表示由 JVM 所侦测到的无法预期的错误，由于这是属于 JVM 层次的严重错误 ，导致 JVM 无法继续执行，因此，这是不可捕捉到的，无法采取任何恢复的操作，顶多只能显示错误信息。

Exception ：表示可恢复的例外，这是可捕捉到的。

Java 提供了两类主要的异常 :runtime exception 和 checked exception 。 checked 异常也就是我们经常遇到的 IO 异常，以及 SQL 异常都是这种异常。 对于这种异常， JAVA 编译器强制要求我们必需对出现的这些异常进行 catch 。所以，面对这种异常不管我们是否愿意，只能自己去写一大堆 catch 块去处理可能的异常。

    但是另外一种异常： runtime exception ，也称运行时异常，我们可以不处理。当出现这样的异常时，总是由虚拟机 接管。比如：我们从来没有人去处理过 NullPointerException 异常，它就是运行时异常，并且这种异常还是最常见的异常之一。

    出现运行时异常后，系统会把异常一直往上层抛，一直遇到处理代码。如果没有处理块，到最上层，如果是多线程就由 Thread.run() 抛出 ，如果是单线程就被 main() 抛出 。抛出之后，如果是线程，这个线程也就退出了。如果是主程序抛出的异常，那么这整个程序也就退出了。运行时异常是 Exception 的子类，也有一般异常的特点，是可以被 Catch 块处理的。只不过往往我们不对他处理罢了。也就是说，你如果不对运行时异常进行处理，那么出现运行时异常之后，要么是线程中止，要么是主程序终止。

    如果不想终止，则必须扑捉所有的运行时异常，决不让这个处理线程退出。队列里面出现异常数据了，正常的处理应该是把异常数据舍弃，然后记录日志。不应该由于异常数据而影响下面对正常数据的处理。 在这个场景这样处理可能是一个比较好的应用，但并不代表在所有的场景你都应该如此。如果在其它场景，遇到了一些错误，如果退出程序比较好，这时你就可以不太理会运行时异常 ，或者是通过对异常的处理显式的控制程序退出。

异常处理的目标之一就是为了把程序从异常中恢复出来 。

 

为什么要在J2EE项目中谈异常处理呢？可能许多java初学者都想说：“异常处理不就是try….catch…finally吗？这谁都会啊！”。笔者在初学java时也是这样认为的。如何在一个多层的j2ee项目中定义相应的异常类？在项目中的每一层如何进行异常处理？异常何时被抛出？异常何时被记录？异常该怎么记录？何时需要把checked Exception转化成unchecked Exception ，何时需要把unChecked Exception转化成checked Exception?异常是否应该呈现到前端页面？如何设计一个异常框架？本文将就这些问题进行探讨。

1． JAVA异常处理
在面向过程式的编程语言中，我们可以通过返回值来确定方法是否正常执行。比如在一个c语言编写的程序中，如果方法正确的执行则返回1.错误则返回0。在vb或delphi开发的应用程序中，出现错误时，我们就弹出一个消息框给用户。
通过方法的返回值我们并不能获得错误的详细信息。可能因为方法由不同的程序员编写，当同一类错误在不同的方法出现时，返回的结果和错误信息并不一致。
所以java语言采取了一个统一的异常处理机制。
什么是异常？运行时发生的可被捕获和处理的错误。
在java语言中，Exception是所有异常的父类。任何异常都扩展于Exception类。Exception就相当于一个错误类型。如果要定义一个新的错误类型就扩展一个新的Exception子类。采用异常的好处还在于可以精确的定位到导致程序出错的源代码位置,并获得详细的错误信息。
Java异常处理通过五个关键字来实现，try,catch,throw ,throws, finally。具体的异常处理结构由try….catch….finally块来实现。try块存放可能出现异常的java语句，catch用来捕获发生的异常，并对异常进行处理。Finally块用来清除程序中未释放的资源。不管理try块的代码如何返回，finally块都总是被执行。
一个典型的异常处理代码
java 代码
  1.   
  2. public String getPassword(String userId)throws DataAccessException{   
  3. String sql = “select password from userinfo where userid=’”+userId +”’”;   
  4. String password = null;   
  5. Connection con = null;   
  6. Statement s = null;   
  7. ResultSet rs = null;   
  8. try{   
  9. con = getConnection();//获得数据连接
      
  10. s = con.createStatement();   
  11. rs = s.executeQuery(sql);   
  12. while(rs.next()){   
  13.      password = rs.getString(1);   
  14. }   
  15. rs.close();   
  16. s.close();   
  17.      
  18. }   
  19. Catch(SqlException ex){   
  20. throw
    new DataAccessException(ex);   
  21. }   
  22. finally{   
  23. try{   
  24.       if(con !=
    null){   
  25.          con.close();   
  26.        }   
  27. }   
  28.     Catch(SQLException sqlEx){   
  29.      throw
    new DataAccessException(“关闭连接失败!”,sqlEx);   
  30.     }   
  31. }   
  32. return password;   
  33. }   
  34.    
可以看出Java的异常处理机制具有的优势：
给错误进行了统一的分类，通过扩展Exception类或其子类来实现。从而避免了相同的错误可能在不同的方法中具有不同的错误信息。在不同的方法中出现相同的错误时，只需要throw 相同的异常对象即可。
获得更为详细的错误信息。通过异常类，可以给异常更为详细，对用户更为有用的错误信息。以便于用户进行跟踪和调试程序。
把正确的返回结果与错误信息分离。降低了程序的复杂度。调用者无需要对返回结果进行更多的了解。
强制调用者进行异常处理，提高程序的质量。当一个方法声明需要抛出一个异常时，那么调用者必须使用try….catch块对异常进行处理。当然调用者也可以让异常继续往上一层抛出。
2． Checked 异常 还是 unChecked 异常？
Java异常分为两大类:checked 异常和unChecked 异常。所有继承java.lang.Exception 的异常都属于checked异常。所有继承java.lang.RuntimeException的异常都属于unChecked异常。
当一个方法去调用一个可能抛出checked异常的方法，必须通过try…catch块对异常进行捕获进行处理或者重新抛出。
我们看看Connection接口的createStatement()方法的声明。
public Statement createStatement() throws SQLException;
      
   SQLException是checked异常。当调用createStatement方法时，java强制调用者必须对SQLException进行捕获处理。
java 代码
  1.        public String getPassword(String userId){   
  2.        try{   
  3.         ……   
  4.                Statement s = con.createStatement();   
  5.                ……   
  6.         Catch(SQLException sqlEx){   
  7.                ……   
  8.     }   
  9. ……   
  10. }   

或者

java 代码
  1. public String getPassword(String userId)throws SQLException{
      
  2.     Statement s = con.createStatement();   
  3. }  
(当然，像Connection,Satement这些资源是需要及时关闭的，这里仅是为了说明checked 异常必须强制调用者进行捕获或继续抛出)
unChecked异常也称为运行时异常，通常RuntimeException都表示用户无法恢复的异常，如无法获得数据库连接，不能打开文件等。虽然用户也可以像处理checked异常一样捕获unChecked异常。但是如果调用者并没有去捕获unChecked异常时，编译器并不会强制你那么做。
比如一个把字符转换为整型数值的代码如下：
java 代码
  1. String str = “123”;   
  2. int value = Integer.parseInt(str);  
parseInt的方法签名为：
java 代码
  1. public
    static
    int parseInt(String s)
    throws NumberFormatException  
当传入的参数不能转换成相应的整数时，将会抛出NumberFormatException。因为NumberFormatException扩展于RuntimeException，是unChecked异常。所以调用parseInt方法时无需要try…catch
因为java不强制调用者对unChecked异常进行捕获或往上抛出。所以程序员总是喜欢抛出unChecked异常。或者当需要一个新的异常类时，总是习惯的从RuntimeException扩展。当你去调用它些方法时，如果没有相应的catch块，编译器也总是让你通过,同时你也根本无需要去了解这个方法倒底会抛出什么异常。看起来这似乎倒是一个很好的办法，但是这样做却是远离了java异常处理的真实意图。并且对调用你这个类的程序员带来误导，因为调用者根本不知道需要在什么情况下处理异常。而checked异常可以明确的告诉调用者，调用这个类需要处理什么异常。如果调用者不去处理，编译器都会提示并且是无法编译通过的。当然怎么处理是由调用者自己去决定的。
       所以Java推荐人们在应用代码中应该使用checked异常。就像我们在上节提到运用异常的好外在于可以强制调用者必须对将会产生的异常进行处理。包括在《java Tutorial》等java官方文档中都把checked异常作为标准用法。
       使用checked异常，应意味着有许多的try…catch在你的代码中。当在编写和处理越来越多的try…catch块之后，许多人终于开始怀疑checked异常倒底是否应该作为标准用法了。
甚至连大名鼎鼎的《thinking in java》的作者Bruce Eckel也改变了他曾经的想法。Bruce Eckel甚至主张把unChecked异常作为标准用法。并发表文章，以试验checked异常是否应该从java中去掉。Bruce Eckel语：“当少量代码时，checked异常无疑是十分优雅的构思，并有助于避免了许多潜在的错误。但是经验表明，对大量代码来说结果正好相反”
关于checked异常和unChecked异常的详细讨论可以参考
使用checked异常会带来许多的问题。
       checked异常导致了太多的try…catch 代码
              可能有很多checked异常对开发人员来说是无法合理地进行处理的，比如SQLException。而开发人员却不得不去进行try…catch。当开发人员对一个checked异常无法正确的处理时，通常是简单的把异常打印出来或者是干脆什么也不干。特别是对于新手来说，过多的checked异常让他感到无所适从。
java 代码
  1.        try{   
  2.         ……   
  3.                Statement s = con.createStatement();   
  4.                ……   
  5.         Catch(SQLException sqlEx){   
  6.                sqlEx.PrintStackTrace();   
  7.     }   
  8.     或者   
  9.        try{   
  10.         ……   
  11.                Statement s = con.createStatement();   
  12.                ……   
  13.         Catch(SQLException sqlEx){   
  14.           //什么也不干
      
  15. }   
checked异常导致了许多难以理解的代码产生
        当开发人员必须去捕获一个自己无法正确处理的checked异常，通常的是重新封装成一个新的异常后再抛出。这样做并没有为程序带来任何好处。反而使代码晚难以理解。
就像我们使用JDBC代码那样，需要处理非常多的try…catch.，真正有用的代码被包含在try…catch之内。使得理解这个方法变理困难起来
checked异常导致异常被不断的封装成另一个类异常后再抛出
java 代码
  1.         public
    void methodA()throws ExceptionA{   
  2.           …..          
  3.           throw
    new ExceptionA();        
  4. }   
  5.           
  6. public
    void methodB()throws ExceptionB{   
  7.    try{   
  8.        methodA();   
  9.        ……   
  10.     }catch(ExceptionA ex){   
  11.    throw
    new ExceptionB(ex);   
  12.     }   
  13. }   
  14.            
  15.          Public void methodC()throws ExceptinC{
      
  16.        try{   
  17.           methodB();   
  18.           …   
  19.         }   
  20.        catch(ExceptionB ex){   
  21.           throw
    new ExceptionC(ex);   
  22.          }   
  23.      }   

我们看到异常就这样一层层无休止的被封装和重新抛出。

checked异常导致破坏接口方法
   一个接口上的一个方法已被多个类使用，当为这个方法额外添加一个checked异常时，那么所有调用此方法的代码都需要修改。
可见上面这些问题都是因为调用者无法正确的处理checked异常时而被迫去捕获和处理，被迫封装后再重新抛出。这样十分不方便，并不能带来任何好处。在这种情况下通常使用unChecked异常。
chekced异常并不是无一是处，checked异常比传统编程的错误返回值要好用得多。通过编译器来确保正确的处理异常比通过返回值判断要好得多。
如果一个异常是致命的，不可恢复的。或者调用者去捕获它没有任何益处，使用unChecked异常。
如果一个异常是可以恢复的，可以被调用者正确处理的，使用checked异常。
在使用unChecked异常时，必须在在方法声明中详细的说明该方法可能会抛出的unChekced异常。由调用者自己去决定是否捕获unChecked异常
倒底什么时候使用checked异常，什么时候使用unChecked异常？并没有一个绝对的标准。但是笔者可以给出一些建议
当所有调用者必须处理这个异常，可以让调用者进行重试操作；或者该异常相当于该方法的第二个返回值。使用checked异常。
这个异常仅是少数比较高级的调用者才能处理，一般的调用者不能正确的处理。使用unchecked异常。有能力处理的调用者可以进行高级处理，一般调用者干脆就不处理。
这个异常是一个非常严重的错误，如数据库连接错误，文件无法打开等。或者这些异常是与外部环境相关的。不是重试可以解决的。使用unchecked异常。因为这种异常一旦出现，调用者根本无法处理。
如果不能确定时，使用unchecked异常。并详细描述可能会抛出的异常,以让调用者决定是否进行处理。

 

返回
【上篇】
【下篇】

作者:

抱歉!评论已关闭.

返回首页

Copyright © 2013-2018 学步园  保留所有权利.
软文销售 QQ客服：2265327166 点击这里给我发消息（其他合作也可洽谈）
必威体育
必威电竞