Harriet — Mon, 03 Dec 2007 02:17:00 GMT

转蝲于：http://www.tangrui.net/2007/01/09/difference-between-java-and-dotnet-on-exception-handling/

关于 Java �?.Net 优劣的争��Z��直在�l�箋�Q�而在异常处理斚w��体现得最为激烈，因�ؓ他们之间的差异是如此明显�?Net 晚于 Java 出现�Q�那�?Java �?.Net ��q��应�v到很重要的借鉴作用�Q�但是伟大的 Anders Hejlsberg ��Z��么没有��l? Java 的实现方式，而是另辟�y�径�Q�这是一个非常值得研究的问题。因为我们要承认一个真理：正确的东西大安��是一��L��正确�Q�错误的却各有个的错误。可以肯定这不可能是 Anders 的疏忽，那么他的道理�I�竟何在�Q�或者说他们之间�I�竟有什么区�?

在你能耐下心来看完�q�篇帖子之前�Q�我惌��明确告诉你一个结论：Java �?.Net 在异常处理的本质上是没有区别的�?/strong>

一、Java 是如何处理异常的

      如果一�?Java �Ҏ��要抛出异常，那么需要在�q�个�Ҏ��后面�?throws 关键字定义可以抛出的异常�c�d��。倘若没有定义�Q�就认�ؓ该方法不抛出��M��异常。如果从�Ҏ��的入口和出口的角度去考虑一下这个规范，我们知道参数可以认�ؓ是方法的入口�Q�当然某些情况下也可以是出口�Q�，而返回值则是方法的出口�Q�这是在�E�序正常执行的情况下�Q�数据从入口入，出口出。要是程序非正常执行�Q��生异常又当如�? 被抛出的异常应该如何从方法中释放出来�? Java 的这�U�语法规范就如同�l�异常开了一个后门，让异常可以堂而皇�?#8220;正确”��C��Ҏ��里被抛出�?/p>
      �q�样的规范决定了 Java 语法必须��对异常进�?try-catch�?/strong>设想一下，对于以下的方法签名：

public void foo() throws BarException { ... }

暗含了两斚w��的意思：�W�一�Q�该�Ҏ��要抛�?BarException �c�d��的异常；�W�二�Q�除�?BarException 外不能抛出其他的异常。而正是这�W�二点的�~�故�Q�我们要如何保证没有�?BarException 之外的�Q何异常被抛出�? 很显�Ӟ��需�? try-catch 其他的异常。也��是��_��一般情况下�Q?strong>�Ҏ��不抛出哪些异常就要在�Ҏ��内部 try-catch �q�些异常�?/strong>

      Java �q�样的机制既有优点，也有�~�点。先来说说优点：

很显�Ӟ��q�种规范是由 Java �~�译器决定的。倘若 Java �E�序的入口点 main() �Ҏ��没有��M��异常抛出�Q�就是说要在 main() �Ҏ��内部�Q�即整个�E�序内部捕捉所有的异常�Q�否则将无法通过�~�译。这��L��译器保证了程序对每个异常都有相应的计划和处理�Q�不会有未处理的异常被泄露到虚拟�? 中，��D��E�序意外中断或退出，也就是增��Z��E�序的健壮性。当�Ӟ��Java �?RuntimeException 的概念，�q�样的异�总�然可以随时被抛出到虚拟机中�?/li>
�� try-catch 要求把异�怽�为程序设计的一部分看待。就如同�Ҏ��的参数和�q�回��g��P��在编写一个方法时�Q�要�l�合上下文做出通盘的考虑和打��。虽然异常是所谓的“意外情况”�Q�但是这�?#8220;例外”理应是被我们全部了解�q�处理的�?/li>
方便调试。异常理应在正确的位�|�被捕捉。当异常发生�Ӟ��我们能更清楚的了解到其来源和相应处理�E�序的位�|�，而免��M��在整个调用栈中摸索的�ȝ��?/li>
在不借助��M��文��的情况下�Q�从�Ҏ��{�֐��可以知晓应该对哪些异常�q�行处理�?/li>

      Java 异常处理机制的这些优点也直接��D��了他的致命弱点：��程序变得异常繁复。往往一个简单的�E�序�Q�功能代码寥寥几行，而异常处理部分却占用了程序的�l�大部分��? �q�；同时��D��~�进深度加深�Q�既不利于书写，也不利于阅读。另外他的强�?try-catch 需要程序员有更高深的造诣�Q�能够通盘考虑异常处理设计问题�Q�这个在�E�序开始之初或者对于初学者是一个不��的门槛。这往往会阻��其推广与发展，因�ؓ低水�q�_�� 学者的信心往往因此而受到打凅R��然而对于高手来��_��~�译器是否能帮助他们扑ֈ�未被处理的异常只是一个方便与否的问题�Q�只要在�~�写�Ҏ��时注意了异常处理�Q�即便没有编译器的支持，情况也不会糟�p�太多。反而倒是�׃��要遵循这样复杂的异常处理规范�Q�以至于大多��C�h都可能�ؓ了图一时方便，对异常的基类�? Exception �?Throwable �q�行�W�统地捕捉，�q�样做的危害��是那些你无法处理的异常被�h��d��处理�E�序中，�Q�按照异常处理原则，我们应该只捕捉那些可以被处理或恢复的异常�Q�而把其他�? 异常�l�箋抛出。至于这样做的优势，以及不这样做所带来的问题，不是一两句能够说清楚，�q�里��׃��展开讨论了。）��D��E�序的不�E�_��和不��定。既没有发挥 Java 语法在这斚w��的优势，反而增加了忧患�?/p>
二�?Net 是如何处理异常的

      一句话概括 .Net 的异常处理方式就是随心所�ƌӀ�没有�h要求你一定要抛出异常�Q�也更没有�h要求你一定要捕捉异常。未被捕捉的异常会被�?Unhandled Exception 的�Ş式抛出到虚拟��Z��。在此我��p��先解决一下文章开头提到的问题�Q��ؓ什么说 Java �?.Net �q�两�U�异常处理机制在本质上是相同的。可以从两个斚w��来考虑�Q?/p>

默认情况下。Java 在默认情况下 main() �Ҏ��是不抛出异常的，正如前面所说的�Q�这要求所有的异常都必��d�� main() �Ҏ��内部被捕捉；�?.Net 则没有这�U�约束，他的 Main() 以至于整个应用程序中的�Q何一个方法对异常都是完全开攄��。这��h��看，�q�两者刚好是对立互补的�?/li>
非默认情况下。Java 可以通过�?main() �Ҏ��后面�?throws 关键字��得整个应用程序对异常开放；�?.Net 则可以通过�l�应用程序域�Q�Application Domain�Q�的 UnhandledException 事�g��d��委托辑ֈ�捕捉所有异常的目的�Q�很昄��q�又是对立互补的�?/li>

因此�Q�就好像一个是“正反”�Q�一个是“反正”�Q�加在一�?#8220;正反反正”都是一��L��Q�对于达到控制异常的目录来说�Q�是没有区别的�?

      很多 Java 爱好者都鄙视 .Net 的这�U�行为，一斚w��他��o�E�序变得不够健壮�Q�因为默认情况下没有强制的办法要求所有的异常都被处理�Q�或被正��处理；另外�Q�他��试增加了困难�Q�不借助文档�? 代码你将无法了解��C��个方法可能抛��Z��么异常，而当一个异常被抛出的时候，同时异常处理代码又写得不够完善，你将不得不仔�l�查看整个调用栈来确定异常出�? 的位�|�，而对于这一�?Java 默认是强制的�?/p>
      但是 Anders 的想法��L��有道理的�?/p>

.Net 代码写�v来非常容易。这是对于初学者，或者那些只是想实现一些测试性小功能的�h而言�Q�你完全没有必要考虑太多异常处理的细节，你要的就是写代码�Q�然后让�? 跑�v来。这��L��单性无疑是你希望看到的�Q�这��L��单性无疑更有利�?.Net 在市��Z��的推�qѝ��由于他在这斚w��q�没有什么理��Z��的漏�z�，也就仍然适合构徏庞大的项目，只是感觉没有那么舒服�|�了�?/li>
一定程度上增加了程序的安全性。难道不捕捉异常可以被成为是安全的吗?�q�个话也许要从另外一斚w��来想�Q�前面说�q�，有些 Java �E�序员（�l�对不占��数�Q��ؓ了图省事�Q�在��捕捉异常的压�q�下�Q�选择捕捉异常的基�c�d��Q�也��是捕捉所有的异常。这样当有你无法处理的异常出现时�Q�他们就溺死在了你的代码中，而外面的�E�序全然不知�Q�还在以一�U�不��定的状态运行着�Q�这��可能是危险的开始。而如果是 .Net�Q�那�?Unhandled Exception 会被虚拟机捕��P��D��E�序异常退出，虽然�q�从面子上对于用户不是一个好的交代，但是深层�ơ地他避免了�E�序在危险的状态下�l�箋�q�行�?/li>

      ��M��Q�萝卜白菜各有所爱。我的这��帖子力求公正地讨论了这个问题，希望能对你有所帮助�?/p>

Harriet 2007-12-03 10:17 发表评论

久久综合欧美,午夜精品区一区二区三,日韩二区三区