只針對異常的狀況才使用異常（57）

• 數組遍歷，使用catch 異常的方式終止循環，不要這樣作

• 標準方式多好

誤覺得第一種方法會提高性能，這種想法錯誤有三：

1. 異常機制的設計初衷是爲了用於不正常情形，因此不多有JVM 設計會對其進行優化
2. 代碼放入 try...catch 裏面反而阻止了 現代jvm的優化動做
3. 標準模式不會致使冗餘的檢查，有些現代jvm 實現會把他優化掉

實際上，現代 JVM 異常模式比標準模式慢得多

• 基於異常的循環模式，模糊了代碼意圖、下降了性能、不能保證正常工做
• 出現了不相關的異常，可能隱藏bug ，增長調試複雜度（好比，try 內調用別的數組，致使越界，這個異常不但被吃掉、數組遍歷也會提早結束）

異常僅僅使用在異常狀況下，他們永遠不該該用於正常的控制流

• 設計良好的api 不該該強迫他的客戶端，使用異常來控制正常的流程

請不要這樣作，老老實實的使用 hasNext（）判斷

狀態測試方法 

• 若是一個類具備一個「狀態相關」的方法，既只有在特定的條件下才能夠被調用的方法,那麼這個類每每也應該有一個單獨的「狀態測試」方法，既只是是否能夠調用第一個方法。例如:Iterator類的hasNext就是一個「狀態測試」方法

可被識別的返回值 

• 返回值。咱們經常使用函數的返回值來標誌成功或者失敗，甚至是失敗的緣由

狀態測試方法 語義明確，相同條件下優先使用

• 但在牽涉到外部未被同步的併發調用時，請使用可被識別的返回值