• 當(dāng)前位置：創(chuàng)新互聯(lián) >> 常見問題 >> 網(wǎng)站程序 >> java教程 >> Java編程中異常處理的優(yōu)劣之道

Java編程中異常處理的優(yōu)劣之道

• 作者：創(chuàng)新互聯(lián) 文章來源：網(wǎng)站程序部 點(diǎn)擊數(shù)： 更新時(shí)間：2008-10-10
• 　　Java編程中的異常處理是一個(gè)很常見的話題了，幾乎任何一門介紹性的Java課程都會(huì)提到異常處理。不過，我認(rèn)為很多人其實(shí)并沒有真正掌握正確處理異常情況的方法和策略，最多也就不過了解個(gè)大概，知道點(diǎn)概念。本文就對(duì)三種不同程度和質(zhì)量的Java異常處理進(jìn)行了討論，所闡述的處理異常的方式按手法的高下分為：
  　　好，不好和惡劣三種。
  　　同時(shí)向你提供了一些解決這些問題的技巧。
  　　首先解釋一些java異常處理中必須搞清楚的定義和機(jī)制。Java語言規(guī)范將自Error類或RuntimeException類衍生出來的任何違例都稱作“不可檢查”（Unchecked）異常；其他所有異常則稱作“可檢查”（Checked）異常。
  　　所謂可檢查異常，是指我們應(yīng)該自行處理的異常。至于處理的手段，要么加以控制（try catch），要么通告（throws）他們有可能產(chǎn)生。通常，應(yīng)捕捉那些已知如何處理的異常，而通告那些不知如何處理的異常。
  　　而對(duì)那些不可檢查異常來說，他們要么在我們的控制之外（Error），要么是我們首先就不該允許的情況（RuntimeException）。
  　　至于異常的指定，Java的規(guī)則非常簡單：一個(gè)方法必須通告自己可能產(chǎn)生的所有可檢查異常。編寫自己的方法時(shí)，并不一定要通告出方法實(shí)際可能產(chǎn)生的每一個(gè)異常對(duì)象，要想理解什么時(shí)候必須要方法的throws叢句來通告異常，就必須知道對(duì)一個(gè)異常來說，他只有可能在下面四種情況下才會(huì)產(chǎn)生：
  　　1.調(diào)用了可能產(chǎn)生異常的方法。比如BufferedReader類的readLine方法。該方法通告java.io.IOException異常
  　　2.偵測到一個(gè)錯(cuò)誤，并用throw語句產(chǎn)生異常。
  　　3.出現(xiàn)一個(gè)編程錯(cuò)誤。比如a[-1] = 0。
  　　4.Java產(chǎn)生內(nèi)部錯(cuò)誤。
  　　如果出現(xiàn)頭兩種情況之一，必須告訴打算使用自己方法的人：假如使用這個(gè)方法，可能造成一個(gè)異常的產(chǎn)生（即在方法頭上使用throws），一個(gè)簡單的記憶方法：
  　　只要含有throw,就要通告throws。如果一個(gè)方法必須同時(shí)處理多個(gè)異常，就必須在頭內(nèi)指出所有異常。就像下例展示的那樣，用逗號(hào)對(duì)他們進(jìn)行分割：
  　　1234567
  　　class Animation
  　　{
  　　public Image loadImage（Strint s）  throws EOFException,MalformedURLException
  　　{ 
  　　 ……
  　　} 
  　　}
  　　然而，我們不需要通告內(nèi)部java錯(cuò)誤，也不應(yīng)該通告自RuntimeException衍生出來的異常。
  　　好的異常處理
  　　好異常處理提供了處理程序錯(cuò)誤的統(tǒng)一機(jī)制。事實(shí)上，Java語言通過向調(diào)用者提出異常警告的方式而顯著地提升了軟件開發(fā)中的異常處理能力。這種方式把Java語言中的“方法（method）”進(jìn)行了擴(kuò)展和增強(qiáng)，使之包括了自身的錯(cuò)誤條件。下面就讓我們看一個(gè)例子，這個(gè)例子說明了這種情況。
  　　以下是FileInputStream構(gòu)造器之一的原型：
  　　public FileInputStream（String name） throws FileNotFoundException Java
  　　的方法和構(gòu)造器必須聲明他們?cè)诒徽{(diào)用時(shí)可能“扔出”的異常，采用的關(guān)鍵字就是“throws”。這種在方法原型中出現(xiàn)的異常提示增加了編程的可靠性。
  　　顯而易見，這種方式是向方法的調(diào)用者提示了可能出現(xiàn)的異常條件，這樣調(diào)用者就可以對(duì)這些異常作出適當(dāng)?shù)南鄳?yīng)處理。以下代碼示意我們是如何捕獲并且處理FileNotFoundException 這一異常的：
  　　1234567891011
      try
      {
      FileInputStream fis = new FileInputStream（args[0]）；
      // other code here …
      }
      catch （FileNotFoundException fnfe）
      {
      System.out.println（"File: " + args[0] + " not found. Aborting."）；
      System.exit（1）；
      }
  　　Java異常處理還有其他一些優(yōu)秀的特性，這就是可檢查異常、用戶定義異常和在JDK 1.4中推出的新型Java記錄API（Java Logging API）。java.lang.Exception的所有子類都屬于可檢查異常�？蓹z查異常（checked exception）是扔出該異常的方法所必須提示的異常，這種異常必須被捕獲或者向調(diào)用者提示。用戶定義異常（User-defined exceptions）是定制的異常類，這種異常類擴(kuò)展了java.lang.Exception類。優(yōu)良的Java程序規(guī)定定制異常封裝、報(bào)告和處理他們自己獨(dú)有的情況。最新的Java記錄API（logging API）則可以集中記錄異常。 不好的Java異常處理
  　　不好的一面包括兩種情況：濫用不可檢查異常（unchecked exceptions）和濫用catchall構(gòu)造器等。這兩種方式都使得問題變得復(fù)雜起來。
  　　有一種類別的異常屬于RuntimeException的子類，這種異常不會(huì)受到編譯器的檢查。比如，NullPointerException和 ArrayStoreException就是這種類型異常的實(shí)例。程序員可以對(duì)RuntimeException進(jìn)行子類化以回避檢查異常的限制，從而便于產(chǎn)生這些異常的方法為其調(diào)用者所使用。
  　　專業(yè)的開發(fā)團(tuán)隊(duì)?wèi)?yīng)當(dāng)只允許在很少的情況下才可以這樣做。
  　　第二種異常處理的陋習(xí)是catchall構(gòu)造器。所謂的“catchall 構(gòu)造器”就是一種異常捕獲代碼模塊，它可以處理所有扔給它的可能異常。
  　　以下是catchall處理器的實(shí)例：
      123456789
      try
      {
      // code here with checked exceptions
      }
      catch （Throwable t）
      {
      t.printStackTrace（）；
      }
  　　我得承認(rèn)，我自己在編寫一般程序的時(shí)候就曾經(jīng)用過這種技術(shù)；但是，在編寫關(guān)鍵程序的時(shí)候這種類型的構(gòu)造器一定要避免使用，除非他們被授權(quán)可以和中央錯(cuò)誤處理器聯(lián)合使用才可以這樣做。
  　　除此之外，catchall構(gòu)造器不過只是一種通過避免錯(cuò)誤處理而加快編程進(jìn)度的機(jī)制。
  　　異常處理的一個(gè)不足之處是難以采用優(yōu)良的錯(cuò)誤處理策略。從低容內(nèi)存狀態(tài)恢復(fù)、寫入錯(cuò)誤和算法錯(cuò)誤等異常情況都不是輕易能得到解決的。你可以嘗試一下循環(huán)、垃圾收集和提醒用戶等常用技術(shù)來應(yīng)付以上的局面。
  　　惡劣的處理方法
  　　和許多Java特性及其API類似，Java的異常處理機(jī)制也有“霸王硬上弓”類的滑稽錯(cuò)誤。比方說，為了扔出某個(gè)異常竟然毫不猶豫地用“new”關(guān)鍵詞為其分配內(nèi)存就是這樣的例子。
  　　我自己不知道有多少次就因?yàn)榉噶诉@種錯(cuò)誤而在嚴(yán)肅的編譯器面前屢屢碰壁。在這種情況下，我們其實(shí)都是在伺候語言而不是讓語言為我們所用。還有我們碰到的OutOfMemoryErrors就是異常處理的缺陷。這一處理過程是：
  　　使用finally模塊關(guān)閉文件，解析異常以得到出現(xiàn)問題的方法和代碼行。在這一過程之內(nèi)最大的缺陷是需要捕獲OutOfMemoryError，而這一異常卻并不是可檢查異常！想想看，內(nèi)存耗盡是相當(dāng)常見的情況。任何與內(nèi)存使用狀態(tài)緊密相關(guān)的程序都應(yīng)當(dāng)捕獲和處理這一錯(cuò)誤。
  　　使用異常時(shí)的一些建議
  　　1.異�？刂频脑O(shè)計(jì)宗旨并不是用來代替一些簡單的測試。只有在異常情況下才使用異常！
  　　2.不要過分細(xì)化異常。不要在每個(gè)語句上都加上異常處理，最好將整個(gè)任務(wù)都放在try塊內(nèi)。如果其中有一項(xiàng)操作失敗，可以隨即放棄任務(wù)。
  　　3.不要“壓制”異常。對(duì)于需要通告異常的方法，我們可以改用捕捉的方法來將異常強(qiáng)行關(guān)閉，如果真的出現(xiàn)異常，那個(gè)異常會(huì)被“靜悄悄”的忽略。如果覺得產(chǎn)生的異常會(huì)非常重要，就必須多費(fèi)些功夫，對(duì)其進(jìn)行正確的控制。
  　　4.不要介意異常的傳遞。如果調(diào)用的方法會(huì)產(chǎn)生異常，比如readLine方法，他們天生就能捕捉自己可能產(chǎn)生的異常，在這種情況下，一種更好地做法是將這些異常傳遞出去，而不是自己動(dòng)手來捕捉它。
• Java讀取配置文件的幾種方法 :上一篇
  java自動(dòng)設(shè)置環(huán)境變量 :下一篇