11.3 使用異常機制的建議
（1）異常處理不能代替簡單的測試。不發生異常時，不要try…catch,這個過程非常耗時。
（2）不要過分細化異常。每句話寫一個try…catch 沒必要（内心OS:正常人不會這麼寫吧？）
（3）利用異常層次結構。不要隻抛出 RuntimeException 異常，适當維護子類（貌似我們還真會這麼幹，因為不用每層都try…catch,清爽多了，有時候我懶得寫直接抓Exception）。個人建議，如果自定義，一定要很清晰的厘清楚哪種異常代表什麼含義，否則下一個人接手隻會讓異常類别越來越不搭。我個人（淺薄）看法其實這裡區分不如實際日志輸出的内容重要。
（4）不要抑制異常。如果一個位置，基本不可能出現異常就不要catch它。（實際上我們公司所有的子產品外層最終都用try…catch包裹了，不希望處理系統莫名的當機問題，有問題就讓它不起作用，但縮小它的危害，不要降低軟體風評，降低不良影響）
（5）檢測錯誤時，要盡量嚴格。比如一段輸出日志内容的拼接串，目前傳入前已經保證資料正确性。但是有了足夠的檢查，後續擴充時就很難發生難以預計的錯誤。（非常贊同。其實有時候是習慣問題，所有輸入，好的代碼都要懷疑傳入資料的正确性，和所有可能産生的錯誤類型。）
（6）不要羞于傳遞異常
有的時候抛出比捕獲更好。比如小明考試送出的考卷有一道題寫錯了。好的做法是告訴他錯了，壞的做法是不批改（小明下次還是不知道怎麼做，還會拿着考卷問你這題對的錯的）。
11.4 斷言
通常進行數值檢查發生錯誤時，會直接抛出異常。可考慮在資料檢查時，使用斷言
這個屬性要配一下，-ea
斷言測試：
public class Main {
public static void main(String[] args) {
Main solution = new Main();
solution.init(-5);
}
public void init(int a){
assert a >= 0;
}
} 換一句再試試（斷言發生錯誤時輸出冒号後面的值）：
assert a >= 0:a;