Effective Java 學習筆記（第57條：只針對異常的狀況才使用異常）

企圖利用java的錯誤判斷機制來提升性能是錯誤的：

1.由於異常機制的設計初衷是用於不正常的情形，因此不多會有JVM實現試圖對它們進行優化，使得與顯式的測試同樣快速。

2.把代碼放在try-catch塊中反而阻止瞭如今JVM實現原本可能要執行的某些特定優化。

3.對數組進行遍歷的標準模式並不會致使冗餘的檢查。有些如今的JVM實現會將它們優化掉。

異常應該只用於異常的狀況下；它們永遠不該該用於正常的流程控制。

設計良好的API不該該強迫它的客戶端爲了正常的控制流而使用異常。

「狀態測試方法」和「可識別的返回值」：

若是對象將在缺乏外部同步的狀況下被併發訪問，或者可被外界改變狀態，使用可被識別的返回值多是頗有必要的，由於在調用「測試狀態」方法和調用對應的「狀態相關」方法的時間間隔之中，對象的狀態有可能發生變化。若是單獨的「狀態測試」方法必須重複「狀態相關」方法的工做，從性能的角度考慮，就應該使用可被識別的返回值。若是全部其餘方面都是等同的，那麼「狀態測試」方法則略猶豫可被識別的返回值。

總而言之，異常是爲了在異常狀況下使用而設計的。不要將它們用於普通的控制流，也不要編寫迫使他們這麼作的API。