C#异常处理经验(原则与方法)

本文是异常处理经验性的文章,其实跟C#关系也不大。比较适合刚刚熟悉异常语法,而缺乏实战的读者。当然,经验老练的读者也可指出不足、给予意见、补充说明,一起完善文章,分享更多知识与经验。

 

1、什么时候该异常处理?

1)代码最外层,如WinFrom,避免用户看到内部异常信息用户体验不好,或者造成程序崩溃,可以用log4net之类的框架记录异常。

2)遇到异常需要恢复状态或者重试的地方。例如连接数据库偶然失败了,可以有个重连机制,在Catch块重新连接数据库。

3)对于一系列有可能失败的任务,其中有一个任务失败,不想影响到其他任务。例如要上传100张图片,不想因为一张图片上传发生异常而失败,进而终止整个上传任务,仅需要记录下失败的图片,提醒用户重传即可。

2、异常处理需要注意的地方

1)Catch和Finally代码应该非常短,而且成功率极高,避免自己又抛出一个异常。否则CLR会终止进程,避免安全漏洞或者不可预知的后果。这个类似于Windows蓝屏,发生了严重的错误,宁愿使系统不可用。

2)Catch块尽量避免直接捕捉异常的基类Exception,而应该捕捉具体的异常类。

3、异常处理的方法和技巧

1)是否能构建统一的框架处理异常,而不用手工来处理呢?

有的人可能会问,能不能偷懒,在一个地方处理异常就行了。如果仅仅是记录异常系统信息,通知到用户,而且这些信息通常是可以缺少一些上下文的,是可以构建同一的机制记录异常信息的。

例如:

WinFrom的Application对象本身就提供了ThreadException时间来捕捉为处理的异常

  static void Main()
        {
            //注册捕捉异常事件
            Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form1());
        }
        static void Application_ThreadException(object sender, System.Threading.ThreadExceptionEventArgs e)
        {
            Exception ex = e.Exception;
            //做一些极其简单的记录异常信息操作
        }

又例如:

WebFrom的Global.asax本身就已经定义了void Application_Error(object sender, EventArgs e) 来处理异常

     void Application_Error(object sender, EventArgs e)
        {
            // 在出现未处理的错误时运行的代码
            Exception ex = Server.GetLastError();
            //处理完异常后清除异常
            Server.ClearError();
        }

但是很多时候,异常处理,不仅仅只是记录到了错误信息就可以了,有时候是需要失败重试或者清理资源等等,因此,仅仅靠统一构建异常处理框架是不够灵活的,

因此可以一方面统一处理,另外一方面特殊的地方可以另外处理。

时间: 2024-10-12 23:51:57

C#异常处理经验(原则与方法)的相关文章

61条面向对象设计的经验原则

你不必严格遵守这些原则,违背它们也不会被处以宗教刑罚.但你应当把这些原则看成警铃,若违背了其中的一条,那么警铃就会响起. -----Arthur J.Riel (1)所有数据都应该隐藏在所在的类的内部.p13 (2)类的使用者必须依赖类的共有接口,但类不能依赖它的使用者.p15 (3)尽量减少类的协议中的消息.p16 (4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝).相等性判断.正确输出内容.从ASCII描述解析等等]. p16 (5)不要把实现细节(例如放置共用代码的私

Delphi面向对象设计的经验原则(61条)

(1)所有数据都应该隐藏在所在的类的内部. (2)类的使用者必须依赖类的共有接口,但类不能依赖它的使用者. (3)尽量减少类的协议中的消息. (4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝).相等性判断.正确输出内容.从ASCII描述解析等等]. (5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中. 如果类的两个方法有一段公共代码,那么就可以创建一个防止这些公共代码的私有函数. (6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口. (7)类之间应该

# 61条面向对象设计的经验原则-《OOD启思录》Arthur J.Riel

61条面向对象设计的经验原则-<OOD启思录>Arthur J.Riel 原文 http://blog.csdn.net/cpluser/article/details/129291 61条面向对象设计的经验原则 摘抄自<OOD 启思录>--Arthur J.Riel 著 鲍志云 译 "你不必严格遵守这些原则,违背它们也不会被处以宗教刑罚.但你应当把这些原则看成警铃,若违背了其中的一条,那么警铃就会响起." ----------Arthur J.Riel (1)

半经验分子轨道方法:初步印象(更新中)

分子轨道理论的两条发展思路: 1.向快速计算发展 – 可以计算更大体系 2.向精确计算发展 Term: Semiempirical implementations of MO 半经验分子轨道方法 半经验方法的核心思路:各种简化久期行列式 半经验方法的具体形式: 1.EHT: Extended Hückel Theory扩展休克尔理论 2.CNDO: Complete Neglect of Differential Overlap以及思路相近的INDO和MINDO.SINDO等 3.NDDO: N

表设计的原则与方法分析:追求表价值的最大化

表设计的原则与方法分析:追求表价值的最大化 在对象关系映射的应用系统设计中,对象就是表.对象关系即表关系,脱离对象设计表是错误的.对象的存在或价值在于它与其他对象的关系(设计研究的就是怎样处理对象以及对象之间的关系),不与其他对象产生关系的对象,或者说不与其他表有关系的表是没有价值的,不应创建. 当需求确定開始对系统进行设计时,首先进行对象分析.每个对象应具有唯一性,即对象的属性和方法唯一,能够明白的代表现实世界中的一种对象,因此与该对象相应的表的字段也具备唯一性.即在其它表中不应有反复字段.

Delphi异常处理的基本原则和方法

一.异常的来源. 在Delphi的应用程序中,下列的情况都比较有可能产生异常.(1)文件处理(2)内存分配(3)Windows资源(4)运行时创建对象和窗体(5)硬件和操作系统冲突 二.异常的处理. (1)try…except…end;在try体内的代码发生异常时,系统将转向except部分进行异常的处理.这是Delphi处理异常的最基本的方式之一. (2)try…finally…end;这种异常处理结构一般用于保护Windows的资源分配等方面,它确保了无论try体内的代码是否发生异常,都需要

职责的界定原则与方法

职责的界定原则与方法 --摘自<公司开了,你该这样管理>作者:张国祥 职责的界定原则 职责界定原则是指企业在进行职责界定时必须遵循的准则.界定职责应该事先约定准则并严格遵守执行. 职责界定的六个原则. 1.战略导向原则.与战略目标相关的事情才能列入企业员工的工作职责,无关战略的职责就是做无用功,除了浪费时间,就是浪费成本.一个代工企业的质检员研究技术升级就不属于本职工作,企业的保安搞产品开发只能算业余爱好.职责只能列入企业必需的工作. 2.单一职责原则.不将同一职责授给二个岗位.职责界定必须体

开放产品开发(OPD):产品负责人的工作原则和方法

产品backlog是如何从产品概念开始而形成的?产品负责人需要定义产品是什么.了解为什么要做,还需要决定何时交付.如何交付,敏捷开发中对产品负责人并没有明确的进行指导.去年在一些大会上分享过敏捷的本质,这是对敏捷团队所有成员的价值观指引.7月26日我将在2014 WOT全球软件技术峰会做相关的一个主题演讲[产品负责人的工作原则和方法],本次分享主要向大家介绍PO和业务需求人员工作中应该遵循的6个原则和相应的一些方法. 以下是本次分享内容: 完整版如下,如果你喜欢想下载的话,点击 http://t

优秀的API接口设计原则及方法(转)

一旦API发生变化,就可能对相关的调用者带来巨大的代价,用户需要排查所有调用的代码,需要调整所有与之相关的部分,这些工作对他们来说都是额外的.如果辛辛苦苦完成这些以后,还发现了相关的bug,那对用户的打击就更大.如果API经常发生变化,用户就会失去对提供方失去信心,从而也会影响目前的业务. 但是我们为什么还要修改API呢?为了API看起来更加漂亮?为了提供更多功能?为了提供更好的性能?还是仅仅觉得到了改变了时候了?对于用户来说,他们更愿意使用一个稳定但是看起来不那么时髦的API,这并不意味着我们