前言
最早最早，我不知道有exception這個東西，之後去博客上找一些不繫統的入門教程，在胎兒時接受了不正確的教育一樣，覺得exception那麼多，又不認識，怪亂七八糟的，反正在我代碼上亂加東西可不行。於是曾幾何時，我在我的代碼裏面寫滿了RuntimeException…一旦違背迅速報錯，中間沒有任何的亂七八糟
追求短平快的我，即使一開始老師講過，看了課件之後也是一個勁的狡辯：“那不是還說有些程序員支持有些程序員反對嗎，那我這麼寫沒問題的，好像老師最早也就只教了那個嘛，再改我真的吐了（HITlab3真的要命）”，現在想想，真就是下圖所示，現在改的代碼全是當時年少無知進的水啊…
這篇文章我就講講我的心路歷程，以及所想所得，吐槽完也只能先繼續屎山了，要不真的是每一天都重寫一遍代碼了
.當時而現在我只想說，珍愛生命，遠離unchecked異常。
unchecked大坑舉例
比如說大家都知道，我們需要在計劃項裏面有這麼一個東西。getResource.負責獲取當前計劃項所具有的資源，但是問題在於，如果現在沒有資源，怎麼處理呢。
很直接的想法就是在調用該方法時，如果嘗試在沒有資源時獲取（我們可以從當前狀態或者資源本身來判斷這一點），就報錯。於是我當時就有了如下看似歲月靜好的代碼：
/**
* 獲取計劃項所具有的資源，返回一個車廂組成的列表，
* 要求已經被分配，如果沒有被分配則拋出異常
*/
public List<Carriage> getResource() {
if(this.state.getState() == State.WAITING) {
throw new RuntimeException("還未分配資源\n");
}
checkRep();
return msr.getResource();
}
就邏輯很簡單，只要違反就拋出一個unchecked異常就完了唄，fallfast，因爲的確你也沒有什麼辦法去解決沒有資源的事實，返回null也是不好的，沒有就是沒有，沒有時候去調用，拋異常無可厚非。
但事情的關鍵就在於我拋出的是一個unchecked異常，真就不是浪得虛名，不見棺材不落淚它是真的不管不提醒啊。在寫完這行代碼之後，我繼續寫了很久才重新在一個比較複雜的情況用到了這行代碼。
在寫api的時候，我需要檢查資源是否衝突，所以我必須要獲取資源，那麼這時候問題來了，假如我本人忘記了我自己給自己定的前置的假設“必須要分配”，或者記錯成了返回不影響結果而直接調用，沒有加任何異常處理機制，那麼勢必會造成傳遞效應，這時候一旦你的測試代碼再寫的不夠全面，這個錯誤就會一直擴散到最最最後面，那後果真就不堪設想（不過我當時是及時發現的）
.....
if(((TrainEntry)preEntry).getResource().contains(r)) {
return preEntry;
}
.....
然而，當時愚鈍的我只是想着填窟窿，我把所有getResource方法的位置都檢查了一遍，確認無誤，萬事大吉。卻沒有反思。設想加入我現在在lab4的時候，一定能保證記得getResource的坑嗎，設想我記住這個了，那其他的坑我有沒有可能只是沒有顯現？我怎麼能保證每時每刻每次都能記下來呢？
答案顯而易見了，也是痛苦的，我需要把這種異常改變成爲checked類型的（自己定義一個最好了），讓他時刻提醒着你去處理，每次你使用都爆紅告訴你需要去處理可能的特殊情況。
所以說所謂checked所帶來的諸多額外的聲明啊，提示啊等等，看似是缺點，實則卻是一個時刻提醒程序員，輔助程序員的優點。一定要儘可能地使用checked異常，只要你覺得這個事情可能發生，除非你覺得，真的絕對不會發生了，發生你也管不了了，或者你真的不會再用繼續開發了（不管了），你真的不必再考慮以後的事情了（屎山老子再也不堆了！），否則一定要用checked exception，讓它成爲你代碼的一部分！！！
總結
- 除非你真的處理不了了，否則一定要用checked異常來提醒自己
- 不要老是幻想着前置一違反自己就可以爲所欲爲，實際上屎山往往是自己享受的
- 軟件構造實驗的痛苦是不可避免的，新的一天，新的bug，新的心得，新的痛苦
- 好好學習，逃離開發崗（✌）