为什么 Java 中要使用 Checked Exceptions

同意在Use Case中的Additional flow做为checked Exception来处理，感觉符合程序的设计合理性和可读性，不过对于多层次的应用时碰到两个问题，特别是分布式应用的时候：
1.如果层次太多，层层上抛确实感觉比较冗余，程序处理其不爽
2.additonal flow在设计中肯定会有遗漏，所以在增加新的Exception时候，在分布式应用中需要两面都增加。

一般情况,设计接口的人往往不能正确的预知方法可能抛出的例外,而方法的实现人员则把常常把checked exception内部消化以保证调试通过,导致异常丢失,所以正确使用checked exception往往不仅在技术上,往往还在协作机制上

《重构》这本书中关于正确使用 Exception 有两个重构方法：
310 页：Replace Error Code with Exception
315 页：Replace Exception with Test

当然，Martin Fowler 说的话并不是圣经，但是他的话是如此中肯以至于我很自然地会首先遵循他的指导。

我同意robbin 的大多数观点, 但对于用异常来实现 use case 中的异常分支,持不同意见,可以说是坚决反对. 关于原因, 参见< effective java> 的 item 39, 我不在此重复. 我只针对robbin 的观点说一下 我的看法.

robbin


我想业务异常(use case 中的异常分支) 和程序中的异常 确实具有相似性,是位于不同层次的相似的东西.但是因为他们位于不同的抽象层,所以应该用不同的技术来实现.  不能因为相似就混同. 举一个不是特别恰当的例子:
    汇编语言中的 mov
    和 C 语言中的 '='  很相似, 但由于是在不同的抽象层次的赋值, 它们有不同的符号.

点到为止.


不过,软件最重要的是结果, 程序能不能正确地完成用户所要求的功能. 从这一点来说, 很多事情都是对的, 一个事情可以有很多 solution , 虽然不是最优, 虽然不优美, 但是work , 却也无可厚非. 因为工程师没有太多的时间去把事情做得完美.

但是从美学, 程序的可维护性, 可理解性, 可修改性等内在质量方面来评价的话, 还是有优劣之分.

我在补充一点：
虽然我认为robbin 的方法不对， 但是还是很有启发性。 在业务建模和将来支持在业务层直接开发的软件工具中， 应该加入支持业务异常的机制， 类似  java 语言对异常的支持， 未来的形式化的建模语言（ 业务语言） 应该加入对业务异常的支持。

信马由缰，扯远了。 :-)

今天和workmate也有了关于异常的争论.

问题是这样:

我们需要实现一个根据一些规则验证url输入的正确性.

我的workmate设计成这样:

bool validateUrl(HttpServletRequest);

我说: 你只能判断输入是否正确, 却不能说哪里出错啊. 为什么不用exception呢? 不管有什么错误, 用exception表示出来, 什么信息都不会丢失.

他说: exception不好. 因为exception不应该参与正常control flow.

我说: 这是你自己的意见. 看你怎么定义control flow了.

他说, 90%的人都这样认为.

我说, 返回bool失去了对错误的fine control.我们只知道是否错了, 不知道错在哪里.

他说, 我们可能不一定需要fine control.

然后争论不休.

最后, 我问他, 那么你怎么告诉别人到底出了什么错呢?

他说: 我可以提供一个getError()函数嘛.

我说: 那么, 你的getError()是否要重新validate一遍输入呢?

他说:那... 我可以返回String

String validateUrl(...);

我说, 光string怎么够呢? 万一我需要在html上面显式错误信息, 我需要格式化的, 如果你的error message有回车, 你还要换成<br>呢.

他说, 不用担心, 我会处理br的. (估计是自己把回车替换成<br>吧)

唉, 我还没敢说, 万一我们需要对同一个错误生成不同的东西呢? 比如, 在数据库里log东西啦; 在html上用各种不同颜色,字体显式不同级别的错误; 给mainframe发送xml信息之类的.
他肯定会说: 没那么复杂的.


我说: 如果你throw exception, adapt成bool是举手之劳. 而如果你返回bool,则不可能转换成throw exception.

反正,这老哥本着一个:不能用exception来处理control flow的教条, 就是不同意用exception.

没办法.

多层次的exception丢出的确很烦很容易不知道在什么地方处理了错误，而且不容易代码理解，不过在处理信息和附加操作上Exception有不可磨灭的作用啊

对一个登录Use Case来说，只有成功才是主事件流，也就是这个Use Case真正的目的，而其他2，3，4的情况都是异常流，因为不是使用者想要的结果。把Exception和Use Case结合，在这点上，我同意robbin的观点

晚上花了好长时间，仔细看完了这个帖子，现在都1点多了。
我就不多说了，
只是说一下：
    1. robbin得观点是十分不正确的（也许是他没表达清楚）。
    2. 这个登陆的例子并不能反应出 robbin 等人要讨论的问题。
    3. 顺便说一下:Exception之所以叫Exception，而不叫SuperIf 是有它的道理的，无论怎么辩驳，常把异常当做分支处理流程，是绝对绝对的错误的。
    4. 有时间给大家写一篇异常的实现原理（包括:C++/Java/C#）合如何使用异常（大概分：业务层应用，系统级应用几个层次）。大家就会比较清脆了。
    5.建议学Java的兄弟，别老是整天玩概念搞框架，有空也去研究研究底层的东东，会对你们有很大帮助。我记得我用java的第二周，就开始负责系统的调优。我记得那回使用经过我改动的框架，系统的综合性能提高了2.5倍，某些模块甚至提高了100倍以上。过多的异常，不适当的new，不合理的过度设计....

睡觉了，对了 再说一下：

    比起这里的各位前辈和大师，我的java经验远不如他们丰富，做的系统可能也不够所谓的“企业级”。大概也就 32个cpu/64Gram * 2 的系统。