异常处理总结 (资料不断整理与收集)

说在前:
    本文描述的异常处理都是个人在以往项目经历中用到的.
    如有相同纯属巧合.
    不同场合不同的方案有不同优势.

     从<(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://www.cnblogs.com/JacksonLin/archive/2008/07/09/1219021.html

By :JacksonLin
Mail: linstreammx@163.com
Trackback:http://www.cnblogs.com/JacksonLin/archive/2008/07/13/1241781.html
原文有彩色，清晰一点
实现驱动编程!