Java程式設計中的異常處理是一個很常見的話題，其實並沒有很多人真正掌握正確處理異常情況的方法和策略，下面是小編為大家整理的Java程式設計中異常處理的方法，歡迎參考~
Java程式設計中的異常處理是一個很常見的話題了，幾乎任何一門介紹性的Java課程都會提到異常處理。不過，我認為很多人其實並沒有真正掌握正確處理異常情況的方法和策略，最多也就不過了解個大概，知道點概念。本文就對三種不同程度和質量的Java異常處理進行了討論，所闡述的處理異常的方式按手法的高下分為：
好，不好和惡劣三種。
同時向你提供了一些解決這些問題的技巧。
首先解釋一些java異常處理中必須搞清楚的定義和機制。Java語言規範將自Error類或RuntimeException類衍生出來的任何違例都稱作“不可檢查”(Unchecked)異常;其他所有異常則稱作“可檢查”(Checked)異常。
所謂可檢查異常，是指我們應該自行處理的異常。至於處理的手段，要麼加以控制(try catch)，要麼通告(throws)他們有可能產生。通常，應捕捉那些已知如何處理的異常，而通告那些不知如何處理的異常。
而對那些不可檢查異常來說，他們要麼在我們的控制之外(Error),要麼是我們首先就不該允許的情況(RuntimeException).
至於異常的指定，Java的規則非常簡單：一個方法必須通告自己可能產生的所有可檢查異常。編寫自己的方法時，並不一定要通告出方法實際可能產生的每一個異常物件，要想理解什麼時候必須要方法的throws叢句來通告異常，就必須知道對一個異常來說，他只有可能在下面四種情況下才會產生：
1.呼叫了可能產生異常的方法。比如BufferedReader類的readLine方法。該方法通告ception異常
2.偵測到一個錯誤，並用throw語句產生異常。
3.出現一個程式設計錯誤。比如a[-1] = 0。
產生內部錯誤。
如果出現頭兩種情況之一，必須告訴打算使用自己方法的人：假如使用這個方法，可能造成一個異常的產生(即在方法頭上使用throws)，一個簡單的記憶方法：
只要含有throw,就要通告throws。如果一個方法必須同時處理多個異常，就必須在頭內指出所有異常。就像下例展示的那樣，用逗號對他們進行分割：
1 2 3 4 5 6 7 | classAnimation { publicImageloadImage(Strints)throwsEOFException,MalformedURLException { ………… } } |
然而，我們不需要通告內部java錯誤，也不應該通告自RuntimeException衍生出來的異常。
好的異常處理
好異常處理提供了處理程式錯誤的統一機制。事實上，Java語言通過向呼叫者提出異常警告的方式而顯著地提升了軟體開發中的異常處理能力。這種方式把Java語言中的.“方法(method)”進行了擴充套件和增強，使之包括了自身的錯誤條件。下面就讓我們看一個例子，這個例子說明了這種情況。
以下是FileInputStream構造器之一的原型：
public FileInputStream(String name) throws FileNotFoundException Java
的方法和構造器必須宣告他們在被呼叫時可能“扔出”的異常，採用的關鍵字就是“throws”。這種在方法原型中出現的異常提示增加了程式設計的可靠性。
顯而易見，這種方式是向方法的呼叫者提示了可能出現的異常條件，這樣呼叫者就可以對這些異常作出適當的相應處理。以下程式碼示意我們是如何捕獲並且處理FileNotFoundException 這一異常的：
1 2 3 4 5 6 7 8 9 10 11 | try{ FileInputStreamfis=newFileInputStream(args[0]); //othercodehere... } catch(FileNotFoundExceptionfnfe) { tln("File:"+args[0]+"ting."); (1); } |
Java異常處理還有其他一些優秀的特性，這就是可檢查異常、使用者定義異常和在JDK 1.4中推出的新型Java記錄API(Java Logging API)。ption的所有子類都屬於可檢查異常。可檢查異常(checked exception)是扔出該異常的方法所必須提示的異常，這種異常必須被捕獲或者向呼叫者提示。使用者定義異常(User-defined exceptions)是定製的異常類，這種異常類擴充套件了ption類。優良的Java程式規定定製異常封裝、報告和處理他們自己獨有的情況。最新的Java記錄API(logging API)則可以集中記錄異常。
不好的Java異常處理
不好的一面包括兩種情況：濫用不可檢查異常(unchecked exceptions)和濫用catchall構造器等。這兩種方式都使得問題變得複雜起來。
有一種類別的異常屬於RuntimeException的子類，這種異常不會受到編譯器的檢查。比如，NullPointerException和 ArrayStoreException就是這種型別異常的例項。程式設計師可以對RuntimeException進行子類化以迴避檢查異常的限制，從而便於產生這些異常的方法為其呼叫者所使用。
專業的開發團隊應當只允許在很少的情況下才可以這樣做。
第二種異常處理的陋習是catchall構造器。所謂的“catchall 構造器”就是一種異常捕獲程式碼模組，它可以處理所有扔給它的可能異常。
以下是catchall處理器的例項：
1 2 3 4 5 6 7 8 9 | try { //codeherewithcheckedexceptions } catch(Throwablet) { tStackTrace(); } |
我得承認，我自己在編寫一般程式的時候就曾經用過這種技術;但是，在編寫關鍵程式的時候這種型別的構造器一定要避免使用，除非他們被授權可以和中央錯誤處理器聯合使用才可以這樣做。
除此之外，catchall構造器不過只是一種通過避免錯誤處理而加快程式設計進度的機制。
異常處理的一個不足之處是難以採用優良的錯誤處理策略。從低容記憶體狀態恢復、寫入錯誤和演算法錯誤等異常情況都不是輕易能得到解決的。你可以嘗試一下迴圈、垃圾收集和提醒使用者等常用技術來應付以上的局面。
惡劣的處理方法
和許多Java特性及其API類似，Java的異常處理機制也有“霸王硬上弓”類的滑稽錯誤。比方說，為了扔出某個異常竟然毫不猶豫地用“new”關鍵詞為其分配記憶體就是這樣的例子。
我自己不知道有多少次就因為犯了這種錯誤而在嚴肅的編譯器面前屢屢碰壁。在這種情況下，我們其實都是在伺候語言而不是讓語言為我們所用。還有我們碰到的OutOfMemoryErrors就是異常處理的缺陷。這一處理過程是：
使用finally模組關閉檔案，解析異常以得到出現問題的方法和程式碼行。在這一過程之內最大的缺陷是需要捕獲OutOfMemoryError，而這一異常卻並不是可檢查異常!想想看，記憶體耗盡是相當常見的情況。任何與記憶體使用狀態緊密相關的程式都應當捕獲和處理這一錯誤。
使用異常時的一些建議
1.異常控制的設計宗旨並不是用來代替一些簡單的測試。只有在異常情況下才使用異常!
2.不要過分細化異常。不要在每個語句上都加上異常處理，最好將整個任務都放在try塊內。如果其中有一項操作失敗，可以隨即放棄任務。
3.不要“壓制”異常。對於需要通告異常的方法，我們可以改用捕捉的方法來將異常強行關閉，如果真的出現異常，那個異常會被“靜悄悄”的忽略。如果覺得產生的異常會非常重要，就必須多費些功夫，對其進行正確的控制。
4.不要介意異常的傳遞。如果呼叫的方法會產生異常，比如readLine方法，他們天生就能捕捉
