對於可恢復/期望恢復的情況，丟擲checked異常
對於程式出錯、不確定是否可恢復，丟擲unchecked異常
盡可能在checked異常中提供方法和豐富的資訊，以便協助恢復
不建議宣告error型別異常、不建議宣告runtimeexception型別的異常
方法要在定義和spec中明確宣告所丟擲的全部checked異常
沒有宣告所有丟擲的checked異常，編譯會出錯
unchecked異常和error可以不用處理
如果子型別中override了父型別中的函式，那麼子型別中方法丟擲的異常不能比父型別丟擲的異常型別更寬泛
子型別方法可以丟擲更具體的異常，也可以不丟擲任何異常
如果父型別的方法未丟擲異常，那麼子型別的方法也不能丟擲異常
利用exception的建構函式，將發生錯誤現場資訊充分的傳遞給client
為了捕獲失敗，異常的細節資訊應該包含「對該異常有貢獻」 所有引數和域的值
出於安全考慮，千萬不要在細節資訊中包含密碼、秘鑰以及類似的資訊！
找到乙個能表達錯誤的jdk提供的exception類/或者構造乙個新的exception類
構造exception類的例項，將錯誤資訊寫入，丟擲它
一旦異常丟擲，方法不會在將控制權返回給呼叫它的client，依次也無需考慮返回錯誤**
如果jdk提供的exception類無法充分描述你的程式發生的錯誤，可以建立自己的異常類
異常發生後，如果找不到處理器，就終止執行程式，在控制台列印出stack trace
當try塊丟擲在catch子句中指定的異常時，將忽略出現異常位置之後的** ，由catch子句進行異常處理
無異常丟擲時，catch子句不執行
如果丟擲的異常，在catch語句中沒有匹配的異常處理，則被訪問的程式退出（由client處理）
也可以不在本方法內處理，而是傳遞給呼叫方，有client處理（「推卸責任」），在某些情況下，client更清楚如何處理
盡量在自己這裡處理，實在不行就往上傳——要承擔責任
但有些時候自己不知道如何處理，那麼就提醒上家，有client自己處理
本來catch語句下面是用來做exception handling的，但也可以在catch裡丟擲異常
這麼做的目的是：更改exception的型別，更方便client端獲取錯誤資訊並處理：是client不依賴於無關不感興趣的低層異常
但是這麼做的時候最好保留「根原因」
當異常丟擲時，方法中正常執行的**被終止
如果異常發生前曾申請過某些資源，那麼異常發生後這些資源要被恰當的**
finally部分的**，是否捕獲異常都會被執行
最好的防禦就是不要引入bug
如果無法避免bugs，嘗試著將bug限制在最小的範圍內
限定在乙個方法/小模組內部，不擴散
盡快失敗，就越容易發現、越早修復
利用斷言，fail fast，避免擴散
檢查前置條件是防禦式程式設計的一種典型形式
斷言：在開發階段的**中嵌入，檢驗某些「假設」是否成立。若成立，表明程式執行正常，否則表明存在錯誤
斷言即是對**中程式設計師所做的假設的文件化，也不會影響執行時的效能（在實際使用時，assertion可以被disabled）
assert condition；
assert condition: message;
所構造的message在發生錯誤時顯示給使用者，便於快速發現錯誤所在
斷言主要用於開發階段，避免引入和幫助發現bug
實際執行階段，不再使用斷言
是要斷言的主要目的時為了在開發階段除錯程式、盡快避免錯誤
執行時斷言不是免費的，且它們會使**混亂不易讀，因此必須謹慎使用
**需要實現的功能，不要出現在斷言中
程式之外的事，不受你控制，不要亂用斷言
斷言只是檢查程式內部裝態是否符合規約
斷言一旦false，程式就停止執行
外部失敗不是bugs，你的**無法保證不出現此類外部錯誤
外部失敗要exception
斷言是非常影響執行時效能的
在其他一些開發者眼裡，不應該針對引數的合法性使用斷言
如果引數來自外部（不受自己控制），使用異常處理
如果來自於自己所寫的其他**，可以使用斷言來幫助發現錯誤（例如：post-condition）
按照慣例，public方法上的前置條件時通過丟擲待定的、指定的異常的顯示檢查來進行的
可以使用斷言將來測試非公共方法的前置條件，當認為無論client對該類做什麼，這些前置條件都正確時（正確性不由client決定）
在public和nonpublic方法中，都可以使用斷言來處理後置條件
斷言和異常處理都可以處理同樣的錯誤
開發階段用斷言盡可能消除bugs
在發行版本裡用異常處理機制處理漏掉的錯誤
2020 03 04軟體構造聽課筆記
以下為2020年3月4日的軟體構造聽課中記錄的知識點 測試是負能量的表現 破壞 證錯 再好的此時也無法證明系統裡不存在錯誤 乙個好的測試的特徵 1.能發現錯誤 2.不冗餘 3.最佳特性最佳方案 4.不太複雜也不太簡單 靜態測試 不執行程式，只分析 動態測試 執行程式，輸入測試用例，檢測是否有問題 測...
2020 04 22軟體構造聽課筆記
除了類本身，設計模式更強調多個類 物件之間的關係和互動過程 比介面 類復用的粒度更大 設計模式分類 建立型模式 結構型模式 行為類模式 adapter模式 介面卡模式 將某個類 介面轉換為client期望的其他形式 解決類之間介面不相容的問題 通過增加乙個介面，將已存在的子類封裝起來，client面...
2020 05 13軟體構造聽課筆記
正確性 程式按照spec加以執行的能力，是最重要的質量指標 正確性 永不給使用者錯誤的結果 健壯性 盡可能保持軟體執行而不是總是退出 健壯性 避免給使用者太大壓力，幫助使用者承擔一些麻煩 可靠性 健壯性 正確性 異常 程式執行中的非正常時間，導致程式無法再按預想的流程執行 exception將錯誤資...