分享
 
 
 

错误处理规范

王朝java/jsp·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

错误处理规范

一、整体规范

按照错误类型,通常的处理方式如下:

错误类型

范围

处理方式

操作员错误

与人机界面交互时不满足输入规则、输入范围等发生的错误

校验用户输入

提示正确规则

强制其改正

运行时错误

与外部资源交互时发生的错误,如网络、文件系统、数据库、其它业务应用系统等

记录并抛出异常

其它详见“异常处理规范”

程序员错误

与客户模块交互时不满足前置条件后置条件发生的错误,如类库被其他程序员调用时参数超出范围等

使用断言

按照调用类型,通常的处理方式如下:

调用类型

处理方式

同步调用

对有能力处理的异常,捕获并处理之

对原始信息过于技术化的异常,捕获并包装之,重新抛出

在调用的中间层,对未知异常保持沉默

在调用的最高层,必须捕获所有异常,避免本身进程或宿主进程崩溃

其它详见“异常处理规范”

异步调用

异步调用一般不应有任何返回值

服务方最好以同样的方式返回正常信息和错误信息,即正常信息是通过通知的方式返回的话,错误信息也应该通过通知的方式返回;正常信息是通过主动查询得到的话,错误信息也应该通过主动查询得到

二、异常处理规范

异常应该是分层的

异常定义

每个模块应该有自己的应用程序异常类型层次,从本模块主动抛出的应用程序异常都应该属于该异常类型层次,客户代码可以只捕捉该层次的基类(?)

应用程序的所有自定义异常都应该从开发平台提供的“应用程序异常基类”派生

中间件等平台程序的运行时异常都应该从开发平台提供的“运行时异常基类”派生(?)

中间件等平台程序的运行时错误都应该从开发平台提供的“错误基类”派生(?)

异常捕获

对有能力处理的异常,捕获并处理之

在调用的中间层,对未知异常保持沉默

在调用的最高层,必须捕获所有异常,避免本身进程或宿主进程崩溃

记录捕获到的每个原始异常的信息

异常抛出

每个模块应使用本模块所能得知的最精确的错误原因报告异常信息

如果有原始异常,在重新抛出的自定义异常中附加原始异常的信息

三、几点说明

错误处理与日志系统

错误处理不等同于日志系统,日志系统只是错误信息的一种记录手段

错误信息的输出应全部调用日志系统来完成

程序员错误与运行时错误

接口函数的前置条件,应该是一种规范,是客户程序员必须遵守的约定;客户程序员违反了约定,程序将产生异常或不可预知的错误;对于这类约定,不应该需要有运行时的代码检查 ;比如如果你的接口函数的一个参数不能为null,而你在函数开始部分程序里写:

if(xxx == null){

throw new someException();

}

你的代码实际上允许该参数为null,因为你对null的情况进行了运行时处理;尽管你在文档里声明该参数不能为null,但如果客户程序员遵守了约定,那么你这段检查代码就是冗余的

当你对参数没有任何检查就进行了使用,而非法的参数值导致了错误,此时有两种情况: 如果你在接口函数说明里列出了参数不允许的非法取值,那么客户程序员应该修改程序避免传入非法值,该类错误称为程序员错误;如果你没有说明,那么你应该修改函数,处理非法参数

不是所有的限制条件在文档里说明一下,就可以把责任扔给客户程序员了,有一些错误必须处理:特别是客户程序员不需要import你的package就可以和你的接口交互的情况,如socket服务器 ,你必须在socket服务程序内部检查所有接收到的数据,拒绝错误的请求,否则极易遭到攻击

错误代码与异常

不应该使用bool值来返回成功与否,bool返回值只应用在真正查询bool状态的操作中,如 bool IsDirty(),bool hasNext()等

整形或bool型的错误代码返回值强迫客户程序员检查每一次调用,应用异常取代之

四、附录

Anders Hejlsberg谈C#异常设计

对Checked Exceptions特性持保留态度

(译者注:在写一段程序时,如果没有用try-catch捕捉异常或者显式的抛出异常,而希望程序自动抛出,一些语言的编译器不会允许编译通过,如Java就是这样。这就是Checked Exceptions最基本的意思。该特性的目的是保证程序的安全性和健壮性。Zee&Snakey(MVP)对此有一段很形象的话,可以参见:http://www.blogcn.com/user2/zee/main.asp。

Bruce Eckel 也有相关的一篇文章(《Does Java need Checked Exceptions》),参见:http://www.mindview.net/Etc/Discussions/CheckedExceptions)

Bruce Eckel:C#没有Checked Exceptions,你是怎么决定是否在C#中放置这种特性的么?

Anders Hejlsberg:我发现Checked Exceptions在两个方面有比较大的问题:扩展性和版本控制。我知道你也写了一些关于Checked Exceptions的东西,并且倾向于我们对这个问题的看法。

Bruce Eckel:我一直认为Checked Exceptions是非常重要的。

Anders Hejlsberg:是的,老实说,它看起来的确相当重要,这个观点并没有错。我也十分赞许Checked Exceptions特性的美妙。但它某些方面的实现会带来一些问题。例如,从Java中Checked Exceptions的实现途径来看,我认为它在解决一系列既有问题的同时,付出了带来一系列新问题的代价。这样一来,我就搞不清楚Checked Exceptions特性是否可以真的让我们的生活变得更美妙一些。对此你或许有不同看法。

Bruce Eckel:C#设计小组对Checked Exceptions特性是否有过大量的争论?

Anders Hejlsberg:不,在这个问题上,我们有着广泛的共识。C#目前在Checked Exceptions上是保持缄默的。一旦有公认的更好的解决方案,我们会重新考虑,并在适当的地方采用的。我有一个人生信条,那就是——如果你对该问题不具有发言权,也没办法推进其解决进程,那么最好保持沉默和中立,而不应该摆出一个非此即彼的架势。

假设你让一个新手去编一个日历控件,他们通常会这样想:“哦,我会写出世界上最好的日历控件!我要让它有各种各样的日历外观。它有显示部分,有这个,有那个……”他们将所有这些构想都放到控件中去,然后花两天时间写了一个很蹩脚的日历程序。他们想:“在程序的下一个版本中,我将实现更多更好的功能。”

但是,一旦他们开始考虑如何将脑海中那么多抽象的念头具体实现出来时,就会发现他们原来的设计是完全错误的。现在,他们正蹲在一个角落里痛苦万状呢,他们发现必须将原来的设计全盘抛弃。这种情况我不是看到一次两次了。我是一个最低纲领主义者。对于影响全局的问题,在没有实际解决方案前,千万不要将它带入到整个框架中去,否则你将不知道这个框架在将来会变成什么样子。

Bruce Eckel:极限编程(The Extreme Programmers)上说:“用最简单的办法来完成工作。”

Anders Hejlsberg:对呀,爱因斯坦也说过:“尽可能简单行事。”对于Checked Excpetions特性,我最关心的是它可能给程序员带来哪些问题。试想一下,当程序员调用一些新编写的有自己特定的异常抛出句法的API时,程序将变得多么纷乱和冗长。这时候你会明白Checked Exceptions不是在帮助程序员,反而是在添麻烦。正确的做法是,API的设计者告诉你如何去处理异常而不是让你自己想破脑袋。

Checked Exceptions的版本相关性

Bill Venners:你提到过Checked Exceptions的扩展性和版本相关性这两个问题。现在能具体解释一下它们的意思么?

Anders Hejlsberg:让我首先谈谈版本相关性,这个问题更容易理解。假设我创建了一个方法foo,并声明它可能抛出A、B、C三个异常。在新版的foo中,我要增加一些功能,由此可能需要抛出异常D。这将产生了一个极具破坏性的改变,因为原来调用此方法时几乎不可能处理过D异常。

也就是说,在新版本中增加抛出的异常时,给用户的代码带来了破坏。在接口中使用方法时也有类似的问题。一个实现特定功能的接口一经发布,就是不可改变的,新功能只能在新版的接口中增加。换句话说,就是只能创建新的接口。在新版本中,你只有两种选择,要么建立一个新的方法foo2,foo2可以抛出更多的异常,要么在新的foo中捕获异常D,并转化为原来的异常A、B或者C。

Bill Venners:但即使在没有Checked Exceptions特性的语言中,(增加新的异常)不是同样会对程序造成破坏么?假如新版foo抛出了需要用户处理的新的异常,难道仅仅因为用户不希望这个异常发生,他写代码时就可以置之不理吗?

Anders Hejlsberg:不,因为在很多情况下,用户根本就不关心(异常)。他们不会处理任何异常。其实消息循环中存在一个最终的异常处理者,它会显示一个对话框提示你程序运行出错。程序员在任何地方都可以使用try finally来保护自己的代码,即使运行时发生了异常,程序依然可以正确运行。对于异常本身的处理,事实上,程序员是不关心的。

很多语言的throws语法(如Java),没必要地强迫你去处理异常,也就是逼迫你搞清楚每一个异常的来源。它们要求你要么捕获声明的异常,要么将它们放入throws语句。程序员为了达到这个要求,做了很多荒谬可笑的事情。例如他们在声明每个方法时,都必须加上修饰语:“throws Exception”。这完全是在搧这个特性的耳光,它不过是要求程序员多作些官样文章,对谁都没有好处。

Bill Venners:如此说来,你认为不要求程序员明确的处理每个异常的做法,在现实中要适用得多了?

Anders Hejlsberg:人们为什么认为(显式的)异常处理非常重要呢?这太可笑了。它根本就不重要。在我印象中,一个写得非常好的程序里,try finally和try catch语句数目大概是10:1。在C#中,也可以使用和类似try finally的using语句(来处理异常)。

Bill Venners:finally到底干了些什么?

Anders Hejlsberg:finally保证你不被异常干扰,但它不直接处理异常。异常处理应该放在别的什么地方。实际上,在任何一个事件驱动的(如现代图形界面)程序中,在主消息循环里,都有一个缺省的异常处理过程,程序员只需要处理那些没被缺省处理的异常。但你必须确保任何异常情况下,原来分配的资源都能被销毁。这样一来,你的程序就是可持续运行的。你肯定不希望写程序时,在100个地方都要处理异常并弹出对话框吧。如果那样的话,你作修改时就要倒大霉了。异常应该集中处理,并在异常来临处保护好你的代码。

Checked Exceptions的扩展性

Bill Venners:那么Checked Exceptions的扩展性又是如何呢?

Anders Hejlsberg:扩展性有时候和版本性是相关的。 在一个小程序里,Checked Exceptions显得蛮迷人的。你可以捕捉FileNotFoundException异常并显示出来,是不是很有趣?这在调用单个的API时也挺美妙的。但是在开发大系统时,灾难就降临了。你计划包含4、5个子系统,每个子系统抛出4到10个异常。但是(实际开发时),你每在系统集成的梯子上爬一级,必须被处理的新异常都将呈指数增长。最后,可能每个子系统需要抛出40个异常。将两个子系统集成时,你将必须写80个throw语句。最后,可能你都无法控制了。

很多时候,Checked Exceptions都会激怒程序员,于是程序员就想办法绕过这个特性。他要么在到处都是写“throws Exception”,要么——我都不知道自己看到多少回了——写“try, da da da da da(译者注:意思是飞快的写一段代码), catch curly curly(译者注:即‘{ }’)”,然后说:“哦,我会回头来处理这些空的异常处理语句的。”实际上,理所当然的没有任何人会回头干这些事情。这时候,Checked Exceptions已经造成系统质量的极大下降。

所以,你可能很重视这些问题,但是在我们决定是否将Checked Exceptions的一些机制放入C#时,却是颇费了一番思量的。当然,知道什么异常可能在程序中抛出还是有相当价值的,有一些工具也可以作这方面的检查。我不认为我们可以建立一套足够严格而严谨的规则(来完成异常检查),因为(异常)还可能是编译器的错误引起的呢。但是我认为可以在(程序)分析工具上下些功夫,检测是否有可疑代码,是否有未捕获的异常,并将这些隐藏的漏洞给你指出来。

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有