異常在我們的平時開發過程中是非常尋常並且經常會面對的，我們有很多方式來處理和使用異常。充分發揮異常的優點可以提高程式的可讀性，可靠性和可維護性。但是如果使用不當，也會帶來很多負面影響。 參考 effective java 第三版中對於異常的一些優秀實踐來做一下總結： No.1 只針對異常的情況才使用 ...
異常在我們的平時開發過程中是非常尋常並且經常會面對的，我們有很多方式來處理和使用異常。充分發揮異常的優點可以提高程式的可讀性，可靠性和可維護性。但是如果使用不當，也會帶來很多負面影響。
參考 effective java 第三版中對於異常的一些優秀實踐來做一下總結：
No.1 只針對異常的情況才使用異常
異常應該只應用於異常的情況下，永遠不要在正常的控制流中使用異常。
例如代碼：
int index = 0;
try{
while(true){
System.out.println(strList.get(index++));
}
}catch (ArrayIndexOutOfBoundsException e){}上圖代碼的功能是遍歷輸出strList集合中的全部元素，但其實我們知道只需要一個foreach就能遍歷輸出
集合中的所有元素。也許可能考慮到了使用正常的foreach會使得每次遍歷的時候都要去檢查當前遍歷索引是否越界，以為該種方式在性能方面會更優於正常的處理方式。實際上該種方式比正常的處理要慢（其中涉及到jvm的優化）。
總而言之，異常是為了在異常情況下使用而設計的，不要在正常的控制流中使用異常。
No.2 對可恢復的情況使用受檢異常，對編程錯誤使用運行時異常
如果期望調用者能夠適當的恢復，就應該使用受檢異常。
用運行時異常來表明編程的錯誤。
你所實現的未受檢異常都應該是RunTimeException的子類。
要在受檢異常上提供方法，以便協助恢復。
不要定義任何既不是受檢異常也不是運行時異常的拋出類型。
No.3 避免不必要的使用受檢異常
受檢異常優點：
不同於返回碼和未受檢異常，受檢異常強迫程式員處理異常的條件，從而增加程式的可靠性
受檢異常缺點：
1.如果方法拋出受檢異常，則調用該方法者就必須在一個try catch塊中對異常進行處理，或者在調用方法中聲明拋出異常並讓他們傳播出去。這給程式員帶來了不少的負擔。
2.拋出受檢異常的方法無法直接在Stream中使用。
對於使用受檢異常的情況應該同時滿足兩個條件：
1.正確的使用該方法或者api的情況下不能防止異常發生
2.一旦產生異常程式員可以採取有效的措施來處理異常
若這兩點沒有同時成立，則更適合使用未受檢異常。
消除受檢異常的方法：
1.方法返回一個optional類型的對象，若遇到異常，則只是返回一個0長度的optional（該方法的缺點是由於只返回一個optional，缺少其他信息，若發生異常追查原因會比較困難）
2.把拋出異常的方法拆分成兩個方法，第一個方法返回一個boolean值，表明是否應該拋出異常，另一個方法則是該方法的處理邏輯。
3.如果程式員知道調用將會成功或者不介意由於異常導致線程被終止。
合理的使用受檢異常可以增加程式的可讀性和可靠性，如果過度使用受檢異常將會給調用者帶來很大的負擔。如果調用者無法恢復異常則應該拋出未受檢異常。如果希望調用者對異常進行處理，首選應該是返回optional值，只有萬一失敗時，這些無法提供足夠的信息來描述異常則考慮使用受檢異常。
No.4 優先使用標準的異常
異常重用，java平臺類庫提供了一組基本的非受檢異常，他們滿足了大多數api的異常拋出需求。
最常被使用到的兩個異常類型：IllegalArgumentException和IllegalStateException。前者代表非法參數異常，後者表示非法狀態異常。可以這麼說，所有錯誤的方法調用都可以歸結為非法參數和非法狀態。另外還有其他異常類也可以表示為非法參數和非法狀態異常
例如：NullPointException IndexOutOfBoundsException等等。
不要直接重用Exception，RunTimeException，Throwable 和 error。可以把這些類看成是抽象類，你無法可靠的測試這些異常，他們是一個方法可能拋出的異常的超類。
如果希望增加更多的失敗捕獲信息，可以子類化標準異常。沒有正當的理由，不應該去編寫額外的異常累，而應該使用java提供的標準異常類。
對某一個異常發生的情況可能同時滿足多個標準異常規範的場合。比如 在長度為10的數組中去取第11個元素。顯然這種情況可以理解參數數值太大（IllegalArgumentException），但是這種異常也可以理解為數組中的元素太少（IllegalStateException）。這裡我們可以規範如果沒有可用的參數值則使用後者異常類，否則使用前者。
No.5 拋出與抽象對應的異常
如果方法拋出的異常和他執行的任務沒有明顯的關聯，這種情形會使人不知所措。方法將他調用的底層方法異常原封不動的向外拋出，例如在一個獲取用戶信息的方法中調用了手機號解碼方法，而該解碼方法剛好發生異常，用戶信息方法將其捕捉之後直接拋出，這就會讓調用獲取用戶信息方法的調用者很困惑，因為他們並不知道獲取用戶信息和解碼異常之間的關係，從而導致問題並不好排查，到底是客戶端傳參數不對還是系統的異常。所有為了避免這個問題，更高層的異常應該捕獲底層的異常，同時拋出可按照高層抽象進行解釋的異常。這過程也叫異常轉譯。
有一種特殊的異常轉譯叫做異常鏈，即底層放入異常被傳到高層的異常，高層的異常提供訪問方法還獲得底層的異常
try {
URLEncoder.encode("ds","utf-8");
} catch (UnsupportedEncodingException e) {
throw new IllegalArgumentException(e);
}如上，高層異常的構造器將原因傳到支持鏈的構造器，從而當異常發生時高層調用者可以調用異常的相關方法來看到底層的異常，另外在列印異常堆棧信息的時候，這樣就可以把底層的異常信息給集成到高層異常中。
異常轉譯相對於直接將底層異常進行拋出會好很多，但我們不應該濫用。對於底層方法的異常我們首先要做的就是應該避免會發生這種異常，例如在調用之前進行參數校驗從而防止異常發生。當然底層方法發生異常時，我們其次想到的應該是在高層方法中悄悄的處理異常，從而將高層方法的調用者和異常進行隔離，使用log對異常進行記錄，這樣有助於排查問題，又可以將客戶端代碼和最終用戶與異常隔離開來。
如果不能阻止並且處理底層異常的發生，我們應該使用異常轉譯，只有底層拋出的異常恰好能表述高層執行任務的情況下，可以將底層異常直接進行拋出。
No.6 每個方法拋出的所有異常都要建立文檔
始終要單獨的申明每一個受檢異常，並且利用javadoc的@throws標簽，準確的記錄下每個異常拋出的條件。並且需要拋出具體的異常類而非異常的基類exception或者throwable。
使用javadoc的@throws標簽記錄一個方法可能會拋出的未受檢異常，但不要使用throws關鍵字將未受檢異常包含在方法申明中。
如果一個類中的許多方法在同樣的情況下都會拋出一致的異常，那麼在該類的文檔註釋中應該對這個異常建立文檔，而不是為每一個方法建立文檔。
No.7 在細節消息中包含失敗-捕獲信息
為了捕獲失敗，異常的細節信息應該包含對異常有貢獻的所有參數和域的值。不過千萬不要在細節中包含密碼，密鑰等敏感信息。
No.8 努力保持失敗的原子性
一般而言，失敗的方法調用應該使對象保持在被調用之前的狀態，具有這種屬性的方法被稱為具有失敗的原子性。
保持失敗的原子性：
1.設計一個不可變的對象。
2.在執行操作之前進行必要的參數有效性校驗，這使得對象狀態被修改之前先拋出適當的異常（調整計算處理的順序，使得任何可能會失敗的計算部分都在對象被修改前發生）。
3.在對象的一份臨時拷貝上進行操作，當操作完成後在用臨時的拷貝來替換原有的對象。
4.寫一段恢復的代碼，讓他來攔截過程中發生的失敗，讓對象回到被調用前的狀態。
錯誤通常是不可恢復的，不要在方法拋出assertionError時，不需要努力的去保持失敗的原子性。
No.9 不要忽略異常
不要忽略異常，忽略異常很簡單，使用一個try 並利用空的catch塊就能忽略異常，但是空的catch達不到應有的目的。我們可以把異常認為是火災而trycatch就像是火警器。當異常發生時我們沒有做任何的處理而是將他忽略。這將導致沒人會在意到這個異常。當真正有一條異常被註意到的時候也許這個異常影響的範圍已經非常大了。
也有一些異常我們是可以忽略的。類似文件讀取，fileStream關閉操作，當我們對文件沒有做任何處理，並且已經讀取到文件中的信息，此時我們可以將異常進行忽略。但是忽略的時候我們應該作出必要的註釋說明。並且將catch中的類變數名設為ignore。
總之，通過忽略異常來解決異常是一件極具風險的事情，我們需要認真對待異常，並且十分清楚問題的原因以及產生的影響。
