CSDN博客

img qiulang

Anders Hejlsberg论为什么不在c#引入类似java的checked exceptions

发表于2003/12/8 21:21:00  601人阅读

Anders Hejlsberg论为什么不在c#引入类似javachecked exceptions

 

这是Anders Hejlsberg发表在http://www.artima.com系列短文中的一篇。这个系列论述了他设计c#的思路,集中讨论了c#中借鉴java地方,读来颇有受益,我便擅自把它翻译成中文。

 

本篇中参与谈论的还有两人,一个是Bruce EckelThinking系列的作者(以下简称BE);一个是Bill Venners,“Inside JVM”作者,www.Artima.com的主编(简称BV)。

 

 

BEC#没有checked exceptions。你是如何决定不把它引入C#中的?

AH:我觉得checked exceptions带来两个问题:可扩展性和版本控制(scalability and versionability)。我知道你也写过关于checked exceptions的文章,你好像也同意我们的观点。[i]

BE:我曾经觉得checked exceptions是个很了不起的创意。

AH:没错。坦率的说,乍看起来,他们确实很棒,而且这个创意本身并没有错。我完全同意checked exceptions是个很好的特性。只是某些特定的实现(比如说,java的实现方式)方式会带来问题。在java你只是把一类问题转换成另一类,我不觉得它(java的方式)使我的生活变得简单,你只是把它变成另一类问题。

BEC#设计小组中的其他成员对这个问题有不同的看法吗?

AH:没有。我想,我们对这个问题达成很广泛的一致。C#现在对这个问题基本上不作表态。一旦我们发现了更好的解决方式,(相信我,我们仍在思考这个问题),我们会把它公布出来。我一直都持这样的观点:如果你对一个问题没有准确的说法,没有一个完美的解决法案,那你干脆什么也不说,而不是试图去建立一个解决它的大框架。

如果你让初级程序员写一个日历控件,他们常常会这样对自己说,“天啊,我决定写一个全世界最棒的日历控件,它将针对不同的历法展现出多态行为。它会有各种花哨的特性。”他们只有两个月的时间来完成这个任务,却把几乎所有的时间用在搭建程序的框架上,而只花两天的时间来写真正有关日历控件的代码。然后,他们不得不自我安慰说,我会在下一版中做得更好些。

这样的设计方法从一开始就错了。而我却不断看到这种现象,一而再,再而三的发生。因此我坚信简单就是美。除非你能解决一个通用问题,否则不要把一个解决特定问题的方法变成一个通用的框架(framework),因为你并不知道该如何设计这个框架。

BE:极限编程说,“用最简单的方法来解决问题”。

AH:是啊,爱因斯坦不也说过,“用最简单的方法来解决问题,但不要过度简单”("Everything should be as simple as possible, but no simpler"),我对checked exceptions的担心是,它增加了程序员的负担。[ii]

当你看到程序员使用了带有throws子句的函数时,他们的代码变得多么扭曲,你就会意识到checked exceptions 其实并没有帮助他们。这实际上是武断的API设计者在告诉使用者,你该怎么怎么办,而不是使用者决定他该怎么怎么办,这根本就是本末倒置!

BV:你提到的可扩展性和版本控制(scalability and versionability)问题,你能进一步澄清一下吗?

AH:好的,我们先来看版本的问题,它比较容易理解。假设,我写了一个foo函数,他丢出三个异常A,B,C。在下一个版本中,我决定对foo增加新的功能,而它也将因此丢出一个新的异常D。这是一个带来麻烦的改变,因为已有的代码如果不作修改,根本无法处理这个新的异常D。也就是说新版本中新异常的出现会给使用它的程序员带来麻烦。这就好像往公有的接口添加一个新的方法一样。而实际上,一个公有的接口,一旦发布会后,就不应该改变的。如果你想添加新的方法,你应该发布一个新的接口。异常情况也类似:你要么写一个全新的方法foo2 丢出A,B,C,D4个异常,要么在你的实现中捕获新的异常D,再将它转换成A,B,C其中的一种。

BV:但是,对于没有checked exceptions的编程语言不也同样存在这个问题吗?如果新版本的foo函数丢出了新异常,使用者不一样也得考虑如何处理他们?这不一样也给他们老代码带来麻烦吗?[iii]

AH:不是这样的。因为在很多情况下,人们不关心(这些异常)。他们也不打算处理这些异常。在他们的消息循环底部有段异常处理代码,这段代码仅仅弹出一个对话框告诉你,出了异常,然后一切继续运转。(实际情况就是这样)。程序员为了保护他们的代码会在所有地方写上try finally,这样当异常出现是他们能正常退出,但他们不关心如何处理这些异常。

java中的实现,throws语句并不强迫你处理异常。如果你不处理他们,java强迫你必须确认有哪些异常会丢出。你或者捕获这些异常,或者把他们放到你的throws子句中。为了避免这样的麻烦,人们会做一些愚蠢的事,比如说他们会在每个函数后加上“throws Exception”,这完全违背了checked exceptions的初衷。当你看到人们些一大堆这样冗长的代码时,你就会意思到checked exceptions根本没有起到任何作用。

BV:所以你认为更多的情况是,人们知道最终会有通用catch块来处理异常,所以他们自己并不处理它们。(So you think the more common case is that callers don't explicitly handle exceptions in deference to a general catch clause further up the call stack?

AH:有意思的是人们为什么会认为异常中重要的是处理它们?这其实并不重要的。我个人认为,一个编写良好的程序,try finally (或C#中的using,类似于try finally)对try catch比例应该是十比一。

BV:什么是finally

AH:在finally中,你可以保护你的代码不受异常的影响,但你并不处理异常。异常处理的代码你可以放在其他的地方。所有事件驱动的程序,像任何一种现代的图像用户程序(modern UI),你会在你消息循环中放一段异常处理代码,只有在程序走到这块时才处理他们。但你必须确认释放了所有资源,做了所有必要的清理工作(在finally块中),这样你才能保护自己始终处在一个一致的,正确的状态。[iv]你不会想要一个程序有100不同的地方来处理异常,并弹出对话框,万一你想改变弹出对话框的方式呢?(那你将修改100处),这太可怕了。所以说处理异常的代码应该集中起来(The exception handling should be centralized)。你只需要在异常被处理前保护好你自己就行了。

BV:那checked exceptions带来的可扩展性问题(scalability)又是什么?

AHscalability versionability 有些关联。在小的程序中,checked exceptions是非常吸引人的。在一个小的程序中,你可以看到你真的捕获FileNotFoundException 异常,这多让人振奋啊!

当你只调用了一个API,确实是这样的。但当你开始构建一个由45子系统组成的大系统时,麻烦就出现了。每个子系统会丢出四到十个异常,这些丢出异常就像一把把梯子,让你爬得越来越高,你是不是开始觉得头晕目眩了?最终你可能碰到一段代码丢出40异常的情况。而当你把这个大系统和另外一个系统结合在一起时,你甚至会丢出80异常,这简直太可怕。

总的来说,当checked exceptions变得无法控制,人们就会采取一些极端的措施来逃避它。所以你会看到他们干脆就写"throws Exception"。我甚至无法告诉你,有多少次我看到人们这样写

try {

…}

catch() {}

catch() {}

他们会自我安慰说,等我有时间了再把catch的代码补上,而实际上他们根本就不会。这种情况下,checked exceptions 实际上降低了代码的质量。

所以,当把所有这些情况都考虑了之后,我决定我需要作更多的思考来决定是否把某种形式的checked exceptions加入C#中。当然,能事先知道什么样的异常会丢出,而且有某种工具来检验无疑是很有价值的。我不认为我们能定下什么严格而有效的规则让编译器来做这个工作,当然我们可以做很多分析工作来检测可疑的代码,推断出有哪些未捕获的异常,并把这些潜在的危险告诉用户。

 

 



[ii] 这个问题,笔者在James Gosling访华时也曾当面问他,可能是由于当时会场的气氛,Gosling只是匆匆的回答说,他并不在意是不是给程序员增加了负担,他在意的是程序的正确性。有意思的是,James Gosling 也在www.artima.com发表他对checked exceptions见解:http://www.artima.com/intv/solid.html

 

[iii] 在“The Design and Evolution of C++” Bjarne Stroustrup也提到,同样也基于对这个问题的考虑,c++没有“Static Checking”(checked exceptions)而是采用“Run time Checking”。而且Stroustrup建议,对于丢出新异常D,可以让它从已有的异常中继承,这样既不影响已有代码,新的代码也可以处理它。(这是Stroustrup在1990就作出的结论!)

[iv] 这其实Stroustrup一再强调的RAII。因为没有析构函数,不得不用finally来模拟。(C++有多少特性从来就没有人很好理解!又有多少人把C++当成C with Class, Sigh!)

阅读全文
0 0

相关文章推荐

img
取 消
img