(资料不断整理与收集,有空再更新)
说在前:
本文描述的异常处理都是个人在以往项目经历中用到的.
如有相同纯属巧合.
不同场合不同的方案有不同优势.
从<(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: JacksonLin.China@gmail.com
原文有彩色,清晰一点
实现驱动编程!