五十七、只針對異常情況才使用異常：

      不知道你否則遇見過下面的代碼：

 這段代碼的意圖不是很明顯，其本意就是遍歷變量數(shù)組range中的每一個元素，并執(zhí)行元素的climb方法，當(dāng)下標(biāo)超出range的數(shù)組長度時，將會直接拋出ArrayIndexOutOfBoundsException異常，catch代碼塊將會捕獲到該異常，但是未作任何處理，只是將該錯誤視為正常工作流程的一部分來看待。這樣的寫法確實(shí)給人一種匪夷所思的感覺，讓我們再來看一下修改后的寫法：

      和之前的寫法相比其可讀性不言而喻。那么為什么又有人會用第一種寫法呢？顯然他們是被誤導(dǎo)了，他們企圖避免for-each循環(huán)中JVM對每次數(shù)組訪問都要進(jìn)行的越界檢查。這無疑是多余的，甚至適得其反，因為將代碼放在try-catch塊中反而阻止了JVM的某些特定優(yōu)化，至于數(shù)組的邊界檢查，現(xiàn)在很多JVM實(shí)現(xiàn)都會將他們優(yōu)化掉了。在實(shí)際的測試中，我們會發(fā)現(xiàn)采用異常的方式其運(yùn)行效率要比正常的方式慢很多。
      除了剛剛提到的效率和代碼可讀性問題，第一種寫法還會掩蓋一些潛在的Bug，假設(shè)數(shù)組元素的climb方法中也會訪問某一數(shù)組，并且在訪問的過程中出現(xiàn)了數(shù)組越界的問題，基于該錯誤，JVM將會拋出ArrayIndexOutOfBoundsException異常，不幸的是，該異常將會被climb函數(shù)之外catch語句捕獲，在未做任何處理之后，就按照正常流程繼續(xù)執(zhí)行了，這樣Bug也就此被隱藏起來。
      這個例子的教訓(xùn)很簡單："異常應(yīng)該只用于異常的情況下，它們永遠(yuǎn)不應(yīng)該用于正常的控制流"。雖然有的時候有人會說這種怪異的寫法可以帶來性能上的提升，即便如此，隨著平臺實(shí)現(xiàn)的不斷改進(jìn)，這種異常模式的性能優(yōu)勢也不可能一直保持。然而，這種過度聰明的模式帶來的微妙的Bug，以及維護(hù)的痛苦卻依然存在。
      根據(jù)這條原則，我們在設(shè)計API的時候也是會有所啟發(fā)的。設(shè)計良好的API不應(yīng)該**它的客戶端為了正常的控制流而使用異常。如Iterator，JDK在設(shè)計時充分考慮到這一點(diǎn)，客戶端在執(zhí)行next方法之前，需要先調(diào)用hasNext方法已確認(rèn)是否還有可讀的集合元素，見如下代碼：

如果Iterator缺少hasNext方法，客戶端則將**改為下面的寫法：

 這應(yīng)該非常類似于本條目開始時給出的遍歷數(shù)組的例子。在實(shí)際的設(shè)計中，還有另外一種方式，即驗證可識別的錯誤返回值，然而該方式并不適合于此例，因為對于next，返回null可能是合法的。那么這兩種設(shè)計方式在實(shí)際應(yīng)用中有哪些區(qū)別呢？
      1. 如果是缺少同步的并發(fā)訪問，或者可被外界改變狀態(tài)，使用可識別返回值的方法是非常必要的，因為在測試狀態(tài)(hasNext)和對應(yīng)的調(diào)用(next)之間存在一個時間窗口，在該窗口中，對象可能會發(fā)生狀態(tài)的變化。因此，在該種情況下應(yīng)選擇返回可識別的錯誤返回值的方式。
      2. 如果狀態(tài)測試方法(hasNext)和相應(yīng)的調(diào)用方法(next)使用的是相同的代碼，出于性能上的考慮，沒有必要重復(fù)兩次相同的工作，此時應(yīng)該選擇返回可識別的錯誤返回值的方式。
      3. 對于其他情形則應(yīng)該盡可能考慮"狀態(tài)測試"的設(shè)計方式，因為它可以帶來更好的可讀性。

五十八、對可恢復(fù)的情況使用受檢異常，對編程錯誤使用運(yùn)行時異常：

      Java中提供了三種可拋出結(jié)構(gòu)：受檢異常、運(yùn)行時異常和錯誤。該條目針對這三種類型適用的場景給出了一般性原則。
      1. 如果期望調(diào)用者能夠適當(dāng)?shù)鼗謴?fù)，對于這種情況就應(yīng)該使用受檢異常，如某人打算網(wǎng)上購物，結(jié)果余額不足，此時可以拋出自定義的受檢異常。通過拋出受檢異常，將**調(diào)用者在catch子句中處理該異常，或繼續(xù)向上傳播。因此，在方法中聲明受檢異常，是對API用戶的一種潛在提示。
      2. 用運(yùn)行時異常來表明編程錯誤。大多數(shù)的運(yùn)行時異常都表示"前提違例"，即API的使用者沒有遵守API設(shè)計者建立的使用約定。如數(shù)組訪問越界等問題。
      3. 對于錯誤而言，通常是被JVM保留用于表示資源不足、約束失敗，或者其他使程序無法繼續(xù)執(zhí)行的條件。
      針對自定義的受檢異常，該條目還給出一個非常實(shí)用的技巧，當(dāng)調(diào)用者捕獲到該異常時，可以通過調(diào)用該自定義異常提供的接口方法，獲取更為具體的錯誤信息，如當(dāng)前余額等信息。

五十九、避免不必要的使用受檢異常：

      受檢異常是Java提供的一個很好的特征。與返回值不同，它們**程序員必須處理異常的條件，從而大大增強(qiáng)了程序的可靠性。然而，如果過分使用受檢異常則會使API在使用時非常不方便，畢竟我們還是需要用一些額外的代碼來處理這些拋出的異常，倘若在一個函數(shù)中，它所調(diào)用的五個API都會拋出異常，那么編寫這樣的函數(shù)代碼將會是一項令人沮喪的工作。
      如果正確的使用API不能阻止這種異常條件的產(chǎn)生，并且一旦產(chǎn)生異常，使用API的程序員可以立即采用有用的動作，這種負(fù)擔(dān)就被認(rèn)為是正當(dāng)?shù)摹３沁@兩個條件都成立，否則更適合使用未受檢異常，見如下測試：

      當(dāng)我們使用受檢異常時，如果在catch子句中對異常的處理方式僅僅如以上兩個示例，或者還不如它們的話，那么建議你考慮使用未受檢異常。原因很簡單，它們在catch子句中，沒有做出任何用于恢復(fù)異常的動作。

六十、優(yōu)先使用標(biāo)準(zhǔn)異常：

      使用標(biāo)準(zhǔn)異常，不僅可以更好的復(fù)用已有的代碼，同時也使你設(shè)計的API更加容易學(xué)習(xí)和使用，因為它和程序員已經(jīng)熟悉的習(xí)慣用法更為一致。另外一個優(yōu)勢是，代碼的可讀性更好，程序員在閱讀時不會出現(xiàn)更多的不熟悉的代碼。該條目給出了一些非常常用且容易被復(fù)用的異常，見下表：
      異常                                               應(yīng)用場合
      IllegalArgumentException              非null的參數(shù)值不正確。
      IllegalStateException                     對于方法調(diào)用而言，對象狀態(tài)不合適。
      NullPointerException                     在禁止使用null的情況下參數(shù)值為null。
      IndexOutOfBoundsException         下標(biāo)參數(shù)值越界
      ConcurrentModificationException   在禁止并發(fā)修改的情況下，檢測到對象的并發(fā)修改。
      UnsupportedOperationException    對象不支持用戶請求的方法。
      當(dāng)然在Java中還存在很多其他的異常，如ArithmeticException、NumberFormatException等，這些異常均有各自的應(yīng)用場合，然而需要說明的是，這些異常的應(yīng)用場合在有的時候界限不是非常分明，至于該選擇哪個比較合適，則更多的需要依賴上下文環(huán)境去判斷。
      最后需要強(qiáng)調(diào)的是，一定要確保拋出異常的條件和該異常文檔中描述的條件保持一致。

六十一、拋出與抽象相對應(yīng)的異常：

      如果方法拋出的異常與它所執(zhí)行的任務(wù)沒有明顯的關(guān)系，這種情形將會使人不知所措。特別是當(dāng)異常從底層開始拋出時，如果在中間層沒有做任何處理，這樣底層的實(shí)現(xiàn)細(xì)節(jié)將會直接污染高層的API接口。為了解決這樣的問題，我們通常會做出如下處理：

 這種處理方式被稱為異常轉(zhuǎn)譯。事實(shí)上，在Java中還提供了一種更為方便的轉(zhuǎn)譯形式--異常鏈。試想一下上面的示例代碼，在調(diào)試階段，如果高層應(yīng)用邏輯可以獲悉到底層實(shí)際產(chǎn)生異常的原因，那么對找到問題的根源將會是非常有幫助的，見如下代碼：

     底層異常作為參數(shù)傳遞給了高層異常，對于大多數(shù)標(biāo)準(zhǔn)異常都支持異常鏈的構(gòu)造器，如果沒有，可以利用Throwable的initCause方法設(shè)置原因。異常鏈不僅讓你可以通過接口函數(shù)getCause訪問原因，它還可以將原因的堆棧軌跡集成到更高層的異常中。
      通過這種異常鏈的方式，可以非常有效的將底層實(shí)現(xiàn)細(xì)節(jié)與高層應(yīng)用邏輯徹底分離出來。   

六十三、在細(xì)節(jié)中包含能捕獲失敗的信息：

    當(dāng)程序由于未被捕獲的異常而失敗的時候，系統(tǒng)會自動地打印出該異常的堆棧軌跡。在堆棧軌跡中包含該異常的字符串表示法，即toString方法的返回結(jié)果。如果我們在此時為該異常提供了詳細(xì)的出錯信息，那么對于錯誤定位和追根溯源都是極其有意義的。比如，我們將拋出異常的函數(shù)的輸入?yún)?shù)和函數(shù)所在類的域字段值等信息格式化后，再打包傳遞給待拋出的異常對象。假設(shè)我們的高層應(yīng)用捕捉到IndexOutOfBoundsException異常，如果此時該異常對象能夠攜帶數(shù)組的下界和上界，以及當(dāng)前越界的下標(biāo)值等信息，在看到這些信息后，我們就能很快做出正確的判斷并修訂該Bug。
    特別是對于受檢異常，如果拋出的異常類型還能提供一些額外的接口方法用于獲取導(dǎo)致錯誤的數(shù)據(jù)或信息，這對于捕獲異常的調(diào)用函數(shù)進(jìn)行錯誤恢復(fù)是非常重要的。

六十四、努力使失敗保持原子性：

      這是一個非常重要的建議，因為在實(shí)際開發(fā)中當(dāng)你是接口的開發(fā)者時，經(jīng)常會忽視他，認(rèn)為不保證的話估計也沒有問題。相反，如果你是接口的使用者，也同樣會忽略他，會認(rèn)為這個是接口實(shí)現(xiàn)者理所應(yīng)當(dāng)完成的事情。
      當(dāng)對象拋出異常之后，通常我們期望這個對象仍然保持在一種定義良好的可用狀態(tài)之中，即使失敗是發(fā)生在執(zhí)行某個操作的過程中間。對于受檢異常而言，這尤為重要，因為調(diào)用者希望能從這種異常中進(jìn)行恢復(fù)。一般而言，失敗的方法調(diào)用應(yīng)該使對象保持在被調(diào)用之前的狀態(tài)。具有這種屬性的方法被稱為具有"失敗原子性"。
      有以下幾種途徑可以保持這種原子性。
      1. 最簡單的方法是設(shè)計不可變對象。因為失敗的操作只會導(dǎo)致新對象的創(chuàng)建失敗，而不會影響已有的對象。
      2. 對于可變對象，一般方法是在操作該對象之前先進(jìn)行參數(shù)的有效性驗證，這可以使對象在被修改之前，拋出更為有意義的異常，如：

     如果沒有在操作之前驗證size，elements的數(shù)組也會拋出異常，但是由于size的值已經(jīng)發(fā)生了變化，之后再繼續(xù)使用該對象時將永遠(yuǎn)無法恢復(fù)到正常狀態(tài)了。
      3. 預(yù)先寫好恢復(fù)性代碼，在出現(xiàn)錯誤時執(zhí)行帶段代碼，由于此方法在代碼編寫和代碼維護(hù)的過程中，均會帶來很大的維護(hù)開銷，再加之效率相對較低，因此很少會使用該方法。
      4. 為該對象創(chuàng)建一個臨時的copy，一旦操作過程中出現(xiàn)異常，就用該復(fù)制對象重新初始化當(dāng)前的對象的狀態(tài)。
      雖然在一般情況下都希望實(shí)現(xiàn)失敗原子性，然而在有些情況下卻是難以做到的，如兩個線程同時修改一個可變對象，在沒有很好同步的情況下，一旦拋出ConcurrentModificationException異常之后，就很難在恢復(fù)到原有狀態(tài)了。

六十五、不要忽略異常：

      這是一個顯而易見的常識，但是經(jīng)常會被違反，因此該條目重新提出了它，如：

      可預(yù)見的、可以使用忽略異常的情形是在關(guān)閉FileInputStream的時候，因為此時數(shù)據(jù)已經(jīng)讀取完畢。即便如此，如果在捕獲到該異常時輸出一條提示信息，這對于挖出一些潛在的問題也是非常有幫助的。否則一些潛在的問題將會一直隱藏下去，直到某一時刻突然爆發(fā)，以致造成難以彌補(bǔ)的后果。
      該條目中的建議同樣適用于受檢異常和未受檢的異常。