|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-04-13
我比较同意 Trustno1 的说法。其实不管是放在 finally {} 里来释放 Connection 还是放在 dispose() 方法中释放 Connection，只要有一个机制能够确保我们无论如何都会释放掉 Connection 就足够了。不一定有了 Checked Exception 才能写出风格良好的代码。
Checked Exception 由语言本身提供是有必要的，减轻了我们很多的工作量，因为还是有很多人发现 Checked Exception 在很多时候是很有用的。但是我们也可以不用 Checked Exception，或者使用把新的 Exception 设置为 RuntimeException 的子类，那样就和 Delphi、C# 差不多了。另外还可以用 Checked Exception 来实现某种流程控制。当然这种流程控制不一定必须要用 Checked Exception 实现，不过它既然已经存在，我们当然要把它的功能充分地利用好。这完全是实用主义的想法，没有必要进行过多的争论。 BTW，NullPointerException 是 Runtime Exception，是捕捉不到的。呵呵。 
|
| 返回顶楼 | |
|
发表时间：2004-04-13
dlee 写道 我比较同意 Trustno1 的说法。其实不管是放在 finally {} 里来释放 Connection 还是放在 dispose() 方法中释放 Connection，只要有一个机制能够确保我们无论如何都会释放掉 Connection 就足够了。不一定有了 Checked Exception 才能写出风格良好的代码。
Checked Exception 由语言本身提供是有必要的，减轻了我们很多的工作量，因为还是有很多人发现 Checked Exception 在很多时候是很有用的。但是我们也可以不用 Checked Exception，或者使用把新的 Exception 设置为 RuntimeException 的子类，那样就和 Delphi、C# 差不多了。另外还可以用 Checked Exception 来实现某种流程控制。当然这种流程控制不一定必须要用 Checked Exception 实现，不过它既然已经存在，我们当然要把它的功能充分地利用好。这完全是实用主义的想法，没有必要进行过多的争论。 BTW，NullPointerException 是 Runtime Exception，是捕捉不到的。呵呵。 流程控制这个东西，如果我没有记错的话在古老的AWT里面丑陋的窗口事件就是靠exception。 另外说一句，异常处理在C++中是个败笔。内存的处理机制，让C++的异常处理陷阱丛生。因此返回值还是c/c++的主要处理方式。 |
| 返回顶楼 | |
|
发表时间：2004-04-20
同意你的说法,其实无论如何,什么exception都不应该出现.
从项目的角度来说,出现printStackTrace()和MessageBox一样,都是bug. 从组织的根源上来说,问题处在not enough test! for example, catch/not catch db conn error 没有区别! 用户都不能工作! 不过使用RuntimeException的子类然后根据Exception的类型Redirect到相应的Error Page确实是还有必要的,because make end-user less worried. Trustno1 写道 robbin 写道 引用 Java 程序仅仅以一长串的stack trace作为代替。对于那些忘记捕捉的exception 来说，无论你是漏掉捕捉还是直接用Exception接掉效果都是一样的。因为该处理的错误你仍然没有处理。
Java强制你catch，所以你不会忘记！当然那种无论什么方法只管throws Exception的程序员就该拉出去痛打了，这不是Java的错，而是程序员的错。 并不是每个Exception都有catch的必要。有些Exception是Bug例如null exception这些Exception是没有必要进行Catch的因为这些Exception即使 Catch了程序也不能正常工作，有些Exception是真正的异常程序需要catch出来进行容错处理例如网络断开。但是一个程序没有Run起来之前，程序员很难判别那些exception是bug，那些是异常；那些是需要Catch的，那些是不需要Catch的。往往都是先catch Exception，然后在Run的时候 根据Exception在应用中的地位选择性的进行catch。有些Exception因为解决了Bug就不存在了，有些Exception则表现为异常需要添加容错代码。 因此在我看来，Java的Check Exception一半是成功的，一半是鸡肋。 成功的一半是接口签名的throws校验，另外一半鸡肋则是throw Exception的时候必须申明接口签名. |
| 返回顶楼 | |
|
发表时间：2004-04-20
我的想法是能不用Checked Exception就不用,实在关键的资源的地方就用把.
而且Exception需要分层次! |
| 返回顶楼 | |
|
发表时间：2004-04-20
我觉得checked exception从组织开发的角度还是需要的，我曾经在项目试图自己捕获异常，然后转换成返回值，希望藉此让后面的开发人员更加逻辑的写代码，结果发现更加难以控制。虽然这和是否使用checked exception无关，但总体上看来有必要使用checked exception，另外exception的层次我觉得并无助于开发工作，相反可能带来复杂性，不同的异常应该尽量保持在平行的层次。
实际上大部分异常在程序中的处理应该是一致的，因为他们都是异常而不是处理结果，程序都不应该有过多的手段去控制，如果程序对异常有不同的反应行为，那说明可能设计上有些混肴了。当然少数情况下用异常统一捕获还是有利于减轻开发负担的。至于异常的消耗问题，我认为在商业开发中基本可以不用考虑。 |
| 返回顶楼 | |
|
发表时间：2004-04-21
TiGEr.zZ 写道 我觉得checked exception从组织开发的角度还是需要的，我曾经在项目试图自己捕获异常，然后转换成返回值，希望藉此让后面的开发人员更加逻辑的写代码，结果发现更加难以控制。虽然这和是否使用checked exception无关，但总体上看来有必要使用checked exception，另外exception的层次我觉得并无助于开发工作，相反可能带来复杂性，不同的异常应该尽量保持在平行的层次。
实际上大部分异常在程序中的处理应该是一致的，因为他们都是异常而不是处理结果，程序都不应该有过多的手段去控制，如果程序对异常有不同的反应行为，那说明可能设计上有些混肴了。当然少数情况下用异常统一捕获还是有利于减轻开发负担的。至于异常的消耗问题，我认为在商业开发中基本可以不用考虑。 我说的分层次不是指Exception的处理分层次,是Exception的类型分层次,至少要分大类,比如交互的错误,配置数据(db conn等等),关键点(Trans的错误),还是OutOfMemory. RuntimeException的子类是主要的目的是为了interface的signature的问题,不是为了其他的. 还有,Exception就是Exception,95%以上的对最终的产品来说就是bug.要靠Unit Test来解决,Exception类别分的粗一点,至少要达到快速的定位错误的目的. |
| 返回顶楼 | |
|
发表时间：2004-04-21
引用 Exception类别分的粗一点,至少要达到快速的定位错误的目的
分得细了才能达到快速的定位错误的目的，你这句话就是矛盾的。 |
| 返回顶楼 | |
|
发表时间：2004-04-22
我比较认同异常作为一种容错处理的手段，也就是无论是程序的内在错误，还是真正的异常，都需要给开发人员和客户一个明晰的态度，无论谁看到屏幕上混乱的东西都会觉得很沮丧。当然这是在我们不可能把所有问题都考虑周全的前提下，而不是放任不负责任的开发行为。
从异常提出的本意是为了一个统一的错误处理出口，是为了更好的对象化（模块化）开发的需要，（当然也可以减轻对goto的依赖，我在不止一个商业开发的产品中看到使用goto作为错误处理的集中出口，这是非常有效的一种手段），减轻程序员的开发负担。如何分类也应该是在这个前提下进行的。往往到了最后，程序应该变的只有一种异常，也就是真正的异常（包括程序错误）。如果最终需要根据不同的异常进行处理的话，应该考虑异常本身的对象化，而不是任由异常扩散，比如你需要展示给用户的错误原因。 |
| 返回顶楼 | |
|
发表时间：2004-04-25
robbin 写道 引用 Exception类别分的粗一点,至少要达到快速的定位错误的目的
分得细了才能达到快速的定位错误的目的，你这句话就是矛盾的。 不好意思,词不达意,我的意思是,Exception最粗的口径至少要达到一定要细到能够到Layer或者Module的层次(根据项目的不同来归集到责任人的目的),然后根据责任人来troubleshooting或者fix! 这是理想的Exception的最低的要求!更高更好,但是成本/复杂度总是一个考量的因素. Sorry,我没说清楚.希望继续拍砖. GUI的Exception一定要用Checked确实是非常重要的,因为用户的交互实在是最最麻烦的事情,好的UI组件能够减少labor提高质量很多. |
| 返回顶楼 | |
|
发表时间：2004-04-25
TiGEr.zZ 写道 我比较认同异常作为一种容错处理的手段，也就是无论是程序的内在错误，还是真正的异常，都需要给开发人员和客户一个明晰的态度，无论谁看到屏幕上混乱的东西都会觉得很沮丧。当然这是在我们不可能把所有问题都考虑周全的前提下，而不是放任不负责任的开发行为。
从异常提出的本意是为了一个统一的错误处理出口，是为了更好的对象化（模块化）开发的需要，（当然也可以减轻对goto的依赖，我在不止一个商业开发的产品中看到使用goto作为错误处理的集中出口，这是非常有效的一种手段），减轻程序员的开发负担。如何分类也应该是在这个前提下进行的。往往到了最后，程序应该变的只有一种异常，也就是真正的异常（包括程序错误）。如果最终需要根据不同的异常进行处理的话，应该考虑异常本身的对象化，而不是任由异常扩散，比如你需要展示给用户的错误原因。 我再续点水. 程序里面永远有Exception,只是rare不rare,严不严重,值不值得fix的问题,哪个大的商用软件的Bug List不是长的不得了,但是不是所有的Bug都要修的,好多都是Workaround?这里就是效益的问题了. 不过一般软件的年龄总是和bug的数量(可以混同Uncaught Exception)成反比的,一般没有什么新的minor bug发现了(不代表它没有),它的生命周期也快进入暮年了.是整个项目结速或者新版本蕴育的时候了,当然总有例外(碰到了是您的幸运). |
| 返回顶楼 | |
