1、拒絕歧視。
? 在一個面向對象系統中，異常毫無疑問也是對象，也應該有其自身的派生體系，有其自身的屬性和方法，而絕不應該僅僅是一個類（EGXXError），一個字符串（Message）和兩個輔助函數（GXXError和GXXErrorFmt）。強類型的異常有助于上層系統或客戶端進行有針對性的截獲和相適應的處理，而弱類型或偽強類型的異常導致的后果，要么是僅此一路的字符迷宮（根據字符串來甄別異常），要么是令人費解的報錯提示（告訴用戶觀察者不存在有意義么）。

2、各守其責。
? 每個模塊有自己關心的異常，也有自己不關心的異常。對于你關心的異常，你盡可以截獲它，并做適當的處理，處理完你可以選擇屏蔽它，也可以重新往外拋。對于你不關心的異常，請留給外層處理，不要搞暗殺。如果某個模塊需要處理的異常太多，那么請考慮這個模塊職責是否太多。雖然我們極力推薦模塊要處理自己關心的異常，但事實證明，很多時候自己都不知道應關心哪些異常，這時候我建議你選擇保守一點，知道幾個就處理幾個，不知道的就不要管。另外，如果是在與界面無關的公共模塊，注意不要貿然越權跟用戶打交道（報錯提示等），因為那不是你的事，做了你不應做的事就意味著你變得專制，很難再被復用了！

3、體貼原則。
? 你確實需要向用戶報告，那么也請盡量體貼注意用戶。首先，你的提示是否確有必要，你是否在讓用戶在重復做無聊的事情；其次，提示信息是否描述準確、完備，用戶會不會因為看不懂而撥打服務熱線，當然，禮貌、溫情而有指導性的信息肯定更好。但即使是好的提示信息也請盡量選擇在合適的地方以合適的方式出現，而不總是冒失地彈出對話框，打斷用戶的思考和操作。對于國際用戶，在提示前你還得選擇合適的語言。總之，把自己作為用戶吧。

3、國際公約。
? 強類型的異常并不是任何時候都是有效的，因為它可能無法跨越系統邊界，比如COM的異常，比如WebService的異常，但你仍然需要流化足夠多的信息以幫助使用者判斷異常的上下文，它可能是一個異常代號加一份幫助文檔，也可能是一段包含必要信息的XML，這就是異常的國際公約。

4、最后防線。
? 應該盡量避免用戶直接面對無人處理的異常，因為用戶不會幫你處理，更不要奢望操作系統能為你做什么，引狼入室的后果是毀掉整個應用程序。因此請在你的應用程序最外層處理掉所有的異常，如果你覺得異常是可以接受的，那么請你提示用戶或記入日志，然后屏蔽它；如果你覺得應用程序已病入膏肓，那么也請你提示用戶并記入日志，并自動關掉程序，避免不好的用戶體驗。

轉載于:https://www.cnblogs.com/zhousl/archive/2008/01/21/1047273.html

總結

以上是生活随笔為你收集整理的异常宣言的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。