(資料不斷整理與收集,有空再更新)
說在前:
本文描述的異常處理都是個人在以往項目經歷中用到的.
如有相同純屬巧合.
不同場合不同的方案有不同優勢.
從<(no廢話)架構設計討論一>改過.原文太沒廢話,我開始吸取教訓.希望大家共同交流與學習.
新文章更多資料更詳細內容.
設計背景:
以.net爲設計背景
資料整理:
1.從零開始學習異常.瞭解與入門
http://www.cnblogs.com/dawave/archive/2008/07/14/1242134.html
2.更深入瞭解異常機制,和它的意義.
http://www.cnblogs.com/anderslly/archive/2007/03/14/understandingexception1.html
3.Enterprise架構中, 及其中異常處理. 是一個很不錯的方案.
http://www.cnblogs.com/jiangshaofen/archive/2007/12/11/990953.html
4.Microsoft官方異常設計準則
http://msdn.microsoft.com/zh-cn/library/ms229014.aspx
5.<.net設計規範>第七章 - 人民郵電出版社 49$
http://www.cnblogs.com/anderslly/archive/2007/03/15/675642.html
更多解決方案.更詳細設計準則.
實踐項目方案一, 散佈式異常處理:
異常處理層包括:
[自定義異常接口], 接口包括必要的處理方法.例如HandleErrorEventArg之類
[自定義異常], 這些異常必須繼承 [自定義異常接口]，接口方法處理異常.
[異常處理中心]:
提供[DependenceProvider] (類似asp.net的MembershipProivder)
之類處理寫日誌和等特殊安全性和特殊業務，事務要求，線程.
[異常處理器]，對繼承 [自定義異常接口] 的 [自定義異常] 進行統一調道
在Global中OnApplicationError事件中(特例ASP.net中,winfrm相似):
這裏可以集中在最後一層處理異常.對UI進行可控或非可控，可提示或非可提示處理
業務邏輯層中的異常:
對可知數據異常和異常處理中心的能異常的異常處理掉後，不能處理再往上拋，拋到UI層
實踐項目方案二, 集中式異常處理:
業務邏輯層中的異常：
對可預知異常都進行處理，不能處理向上拋。
[自定義異常]與異常層庫：
[自定義異常]在構造時完成處理
面向服務的Service層 [異常處理中心] :
對所有[自定義異常]集中式處理，處理後返回結果到所須的層.
若不能處理的作系統異常.
帶 [DependenceProvider] 之類
通常使用方案三, 原始處理：
那裏出問題那裏處理，適合研發階段的開發
說在後：
關於包裝異常，異常最內纔是根源。
要對性能，可維護，進行綜合監控.
注意異常處理中,集中處理會不會拋出更多異常.和異常性能問題.
討論線：
對不同方案提出個人要點，以及指出出現不能處理的缺點.
提供更多可參考資料
文章目錄:http://blog.csdn.net/linjiachenggz/archive/2008/09/01/2861617.aspx
TrackBack:http://blog.csdn.net/linjiachenggz/archive/2008/09/01/2861742.aspx
By :JacksonLin
Mail: [email protected]
原文有彩色，清晰一點
實現驅動編程!