關鍵字: 異常 通告(throws) throw try catch RuntimeException 不可檢查(Unchecked)異常 可檢查(Checked)異常Java編程中的異常處理是壹個很常見的話題了 幾乎任何壹門介紹性的Java課程都會提到異常處理 不過 我認為很多人其實並沒有真正掌握正確處理異常情況的方法和策略 最多也就不過了解個大概 知道點概念 本文就對三種不同程度和質量的Java異常處理進行了討論 所闡述的處理異常的方式按手法的高下分為
好 不好和惡劣三種
同時向妳提供了壹些解決這些問題的技巧首先解釋壹些java異常處理中必須搞清楚的定義和機制 Java語言規範將自Error類或RuntimeException類衍生出來的任何違例都稱作 不可檢查 (Unchecked)異常;其他所有異常則稱作 可檢查 (Checked)異常所謂可檢查異常 是指我們應該自行處理的異常 至於處理的手段 要麽加以控制(try catch) 要麽通告(throws)他們有可能產生 通常 應捕捉那些已知如何處理的異常 而通告那些不知如何處理的異常而對那些不可檢查異常來說 他們要麽在我們的控制之外(Error) 要麽是我們首先就不該允許的情況(RuntimeException)至於異常的指定 Java的規則非常簡單 壹個方法必須通告自己可能產生的所有可檢查異常 編寫自己的方法時 並不壹定要通告出方法實際可能產生的每壹個異常對象 要想理解什麽時候必須要方法的throws叢句來通告異常 就必須知道對壹個異常來說 他只有可能在下面四種情況下才會產生 ．調用了可能產生異常的方法 比如BufferedReader類的readLine方法 該方法通告java io IOException異常 ．偵測到壹個錯誤 並用throw語句產生異常 ．出現壹個編程錯誤 比如a[ ] = ．Java產生內部錯誤如果出現頭兩種情況之壹 必須告訴打算使用自己方法的人 假如使用這個方法 可能造成壹個異常的產生(即在方法頭上使用throws) 壹個簡單的記憶方法只要含有throw 就要通告throws 如果壹個方法必須同時處理多個異常 就必須在頭內指出所有異常 就像下例展示的那樣 用逗號對他們進行分割
class Animation { public Image loadImage(Strint s) throws EOFException MalformedURLException { ………… } }
然而 我們不需要通告內部java錯誤 也不應該通告自RuntimeException衍生出來的異常 好異常處理 好異常處理提供了處理程序錯誤的統壹機制 事實上 Java語言通過向調用者提出異常警告的方式而顯著地提升了軟件開發中的異常處理能力 這種方式把Java語言中的 方法（method） 進行了擴展和增強 使之包括了自身的錯誤條件 下面就讓我們看壹個例子 這個例子說明了這種情況 以下是FileInputStream構造器之壹的原型 public FileInputStream(String name) throws FileNotFoundException Java 的方法和構造器必須聲明他們在被調用時可能 扔出 的異常 采用的關鍵字就是 throws 這種在方法原型中出現的異常提示增加了編程的可靠性顯而易見 這種方式是向方法的調用者提示了可能出現的異常條件 這樣調用者就可以對這些異常作出適當的相應處理 以下代碼示意我們是如何捕獲並且處理FileNotFoundException 這壹異常的
try { FileInputStream fis = new FileInputStream(args[ ]); // other code here } catch (FileNotFoundException fnfe) { System out println( File: + args[ ] + not found Aborting ); System exit( ); }
Java異常處理還有其他壹些優秀的特性 這就是可檢查異常 用戶定義異常和在JDK 中推出的新型Java記錄API（Java Logging API） java lang Exception的所有子類都屬於可檢查異常 可檢查異常（checked exception）是扔出該異常的方法所必須提示的異常 這種異常必須被捕獲或者向調用者提示 用戶定義異常（User defined exceptions）是定制的異常類 這種異常類擴展了java lang Exception類 優良的Java程序規定定制異常封裝 報告和處理他們自己獨有的情況 最新的Java記錄API（logging API）則可以集中記錄異常 不好 Java異常處理 不好的壹面包括兩種情況 濫用不可檢查異常（unchecked exceptions）和濫用catchall構造器等 這兩種方式都使得問題變得復雜起來有壹種類別的異常屬於RuntimeException的子類 這種異常不會受到編譯器的檢查 比如 NullPointerException和 ArrayStoreException就是這種類型異常的實例 程序員可以對RuntimeException進行子類化以回避檢查異常的限制 從而便於產生這些異常的方法為其調用者所使用 專業的開發團隊應當只允許在很少的情況下才可以這樣做第二種異常處理的陋習是catchall構造器 所謂的 catchall 構造器 就是壹種異常捕獲代碼模塊 它可以處理所有扔給它的可能異常 以下是catchall處理器的實例我得承認 我自己在編寫壹般程序的時候就曾經用過這種技術 但是 在編寫關鍵程序的時候這種類型的構造器壹定要避免使用 除非他們被授權可以和中央錯誤處理器聯合使用才可以這樣做 除此之外 catchall構造器不過只是壹種通過避免錯誤處理而加快編程進度的機制異常處理的壹個不足之處是難以采用優良的錯誤處理策略 從低容內存狀態恢復 寫入錯誤和算法錯誤等異常情況都不是輕易能得到解決的 妳可以嘗試壹下循環 垃圾收集和提醒用戶等常用技術來應付以上的局面 惡劣 和許多Java特性及其API類似 Java的異常處理機制也有 霸王硬上弓 類的滑稽錯誤 比方說 為了扔出某個異常竟然毫不猶豫地用 new 關鍵詞為其分配內存就是這樣的例子 我自己不知道有多少次就因為犯了這種錯誤而在嚴肅的編譯器面前屢屢碰壁 在這種情況下 我們其實都是在伺候語言而不是讓語言為我們所用 還有我們碰到的OutOfMemoryErrors就是異常處理的缺陷 這壹處理過程是使用finally模塊關閉文件 解析異常以得到出現問題的方法和代碼行 在這壹過程之內最大的缺陷是需要捕獲OutOfMemoryError 而這壹異常卻並不是可檢查異常！想想看 內存耗盡是相當常見的情況 任何與內存使用狀態緊密相關的程序都應當捕獲和處理這壹錯誤 使用異常時的壹些建議 ．異常控制的設計宗旨並不是用來代替壹些簡單的測試 只有在異常情況下才使用異常！ ．不要過分細化異常 不要在每個語句上都加上異常處理 最好將整個任務都放在try塊內 如果其中有壹項操作失敗 可以隨即放棄任務 ．不要 壓制 異常 對於需要通告異常的方法 我們可以改用捕捉的方法來將異常強行關閉 如果真的出現異常 那個異常會被 靜悄悄 的忽略 如果覺得產生的異常會非常重要 就必須多費些功夫 對其進行正確的控制 ．不要介意異常的傳遞 如果調用的方法會產生異常 比如readLine方法 他們天生就能捕捉自己可能產生的異常 在這種情況下 壹種更好地做法是將這些異常傳遞出去 而不是自己動手來捕捉它 lishixinzhi/Article/program/Java/hx/201311/26508