38、只針對不正常的條件使用異常
異常只應該被用于不正常的條件，它們永遠不應該被用于不正常的條件
設計API啟示：一個良好的API不應該強迫它的客戶為了正常的控制流而使用異常。對于邊界的判斷常用的有兩種方法：狀態測試方法和可被識別的返回值

40、對于可以恢復的條件使用被檢查的異常，對于程序錯誤使用運行時異常
 Thowable（可拋出異常）有三種結構：被檢查的異常(checked exception)、運行時異常（run-time exception)和錯誤(error)
如果期望調用者能夠恢復，那么，對于這樣的條件應該使用被檢查的異常
運行時異常和錯誤，不需要也不應該是被捕獲的拋出物
用運行時異常來指明程序錯誤
對于被檢查的異常，提供一些輔助方法是非常重要的，通過這些方法，調用者可以獲得一些有助于恢復的信息

41、避免不必要地使用被檢查的異常

42、盡量使用標準異常
      

43、拋出的異常要適合于相應的抽象
高層的實現應該捕獲低層的異常，同時導出一個可以按照高層抽象進行解釋的---異常轉譯
低層的異常對于調試該異常被撥出的情形非常有幫助的話，可以使用異常鏈接。即低層的異常被高層的異常保存起來，并且高層的異常提供一個公有的訪問方法來獲得低層異常

44、每個異常的拋出都必須有文檔

45、在細節消息中包含失敗--捕獲信息
為了捕獲失敗，一個異常的的字符串表示應該包含所有“對異常有貢獻”的參數和域的值
在異常構造函數中以參數形式引入這些信息

46、努力使失敗保持原子性
一個失敗方法調用應該使用對象保持“它在被調用之前的狀態” ---failure atomic
幾種解決方法：在執行操作之前檢查參數的有效性
調整計算機過程，使得任何可能會失敗的計算部分發生在對象狀態被修改之前
編寫一段恢復代碼
在對象上臨時都拷貝一份，當操作完成之后把臨時拷貝中的結果復制給原來的對象。如：Collections.sort

47、不要忽略異常
寫上try catch塊