今天在學習設計模式時看到"assert"關鍵字，發現跟exception類似。功能上同樣是捕捉程式錯誤抛出異常，那麼什麼時候改用斷言assert，什麼時候該用異常exception呢，在做了相關搜尋後發現知乎@vczh說的很清楚很直白一下就懂了。他的原話是
assert用在那些你知道絕對不會發生的事情上，但是因為人總是會犯錯誤，保不準你寫出來的東西跟你想的不一樣。是以assert用來捕捉的是程式員自己的錯誤。
同理，exception捕捉的是使用者或者環境的錯誤。
assert用于捕捉程式員自己的錯誤，exception用于捕捉使用者的錯誤。在實際多人合作開發中，經常會有寫公用方法的情況，方法不能保證其他程式員傳入的參數是正确的，每當發生錯誤時，都要一步一步debug過來（當然對錯誤清楚的例外），這裡如果是用斷言校驗的話就能很直覺的将錯誤資訊回報給程式員，這還是很友善的。
assert相當于“契約程式設計設計”的先驗條件，雖然平時在開發中經常隻是口頭說一聲，或者隻是在代碼上注釋一下（我們公司小吧，口頭先驗條件
轉存失敗重新上傳取消
）。關于"契約程式設計設計"看了百度百科的介紹，有了簡單的了解，發現還是比較好了解的。在提供方法的A和調用方法的B商量好，“A會保證參數傳入的正确，B會保證完成服務并傳回資訊。在達成以上契約後，B就不需要花很大精力去處理A的輸入問題，在A提供正确輸入後，B也能保證品質的傳回A所需要的資料。
摘錄下百科的話：
契約式設計的三個關鍵詞
一 前置條件（precondition）：
為了調用函數，必須為真的條件，在其違反時，函數決不調用，傳遞好資料是調用者的責任。
二 後置條件 （postcondition）：
函數保證能做到的事情，函數完成時的狀态，函數有這一事實表示它會結束，不會無休止的循環
三 類不變項（class invariant）：
從調用者的角度來看，該條件總是為真，在函數的内部處理過程中，不變項可以為變，但在函數結束後，控制傳回調用者時，不變項必須為真。
為了調用函數，必須為真的條件，在其違反時，函數決不調用，傳遞好資料是調用者的責任。
二 後置條件 （postcondition）：
函數保證能做到的事情，函數完成時的狀态，函數有這一事實表示它會結束，不會無休止的循環
三 類不變項（class invariant）：
從調用者的角度來看，該條件總是為真，在函數的内部處理過程中，不變項可以為變，但在函數結束後，控制傳回調用者時，不變項必須為真。 契約就是這些權利和義務的正式形式。我們可以用“三個問題”來總結DbC(Database Commander)，并且作為設計者要經常問：
1.它期望的是什麼？
2.它要保證的是什麼？
3.它要保持的是什麼？ Commander)，并且作為設計者要經常問：
1.它期望的是什麼？
2.它要保證的是什麼？
3.它要保持的是什麼？ 突然發現，講的很有道理啊，assert用來捕捉程式員的錯誤，因為在調試中如果出現類似程式員的錯誤時，程式不需要再運作下去了，而且程式員的輸入也是能夠保證的，不能保證就去揍那程式員。而exception用來捕捉使用者的錯誤，畢竟誰也不能保證使用者會輸入什麼，是以前後端才需要那麼多校驗，但是就算使用者輸入錯誤或非法輸入，也不能讓程式挂掉，畢竟還有其他呢麼多使用者和業務，而且體驗也不好。
這篇就這樣了，後面有需求再改。剛開始寫部落格，沒有什麼幹貨，技術上也拿不出什麼幹活，就是寫寫讀後感，友善以後自己浏覽，有不對的地方希望指正。
文中連結：
https://www.zhihu.com/question/24461924
https://baike.baidu.com/item/契約式設計/2180000?fr=aladdin