为什么 Java 中要使用 Checked Exceptions

可以反过来想：既然频繁出现这个情况，要么是确实有某种错误存在（例如数据完整性被破坏导致频频抛出异常），要么这就不是一个“异常”的情况，而是正常的程序逻辑流。异常应该用于描述“异常”的情况，不应该用来做流程控制。当程序正常运转时，异常——不管是checked还是unchecked，不管在catch段里的代码是多是少——应该是很少出现的。

按Robbin的看法，是不是有一天我们应该写：

catch (UserLoginSuccessException ulse) {
}

如果你的业务就要求：不应该有人成功登陆进来。那么这样的代码是完全合理的。

譬如说，CSDN的后台管理系统只能在内网登陆。那么如果在外网登陆成功了，确实应该进这样一个异常。

gigix, 谢谢你给这段代码加上了一个合理的场景:)那么当有人从内网成功登录是不是应该：

catch (InternalUserLoginSuccessException ulse) {
    // ...
    log.info("login success, you can use it now");
}

这应该算是主事件流，怎么能算异常流呢？

因为我想，按照前面讨论的论点，如果用面向对象的方法做设计，需要象这样：

catch (PasswordNotMatchException pnme); {
     return wrong_password.action
}
catch (...); {
}

那么，当成功登录的主事件流，不是也应该

catch (LoginSuccessException lse); {
     return login_success.action
}

么

确实是某种错误存在！我举这个例子只是想说Exception对性能有一定的影响，
亦不能滥用。对性能问题，我们的一般处理方法（特别是系统大的框架已经做
好的情况下）：
1、先假设不是性能问题，而是系统参数、网络配置等问题，企业应用的性能
  问题大多是参数配置不当引起，特别是J2EE应用。然后用性能测试工具重现性
  能问题，如：LoadRunner。分析问题在那里，调整后再测试。
2、最后才考虑是不是代码的问题。
当然在系统刚开始设计时亦要考虑性能的问题，一些模块可能对系统的性能有
大的影响，如：批处理、大的查询、缓存的设计等。而在其它地方我感觉就没
必要为多new几个对象而发愁会不会影响性能。

对中间件开发而言，checked exception的使用将会破坏信息封装的原则。
实际上，当软件的调用层次比较深时，一般不可能在最底层进行有意义的异常处理。一个功能模块必须集中处理异常。这要求异常将被接力抛出，直到到达合适的处理层次。如果调用层次中的每一个函数都明确知道checked exception但又不处理，就破坏了封装性原则

Exception实际上代表了一个UseCase中的异常流的处理.
UseCase是用于捕获用户需求的.
如果我不用usecase呢?
异常没必要弄得那么复杂把?
异常的处理应用级上要根据需求,系统级上要根据程序的流程.

Exception实际上代表了一个UseCase中的异常流的处理.
UseCase是用于捕获用户需求的.
quote]

个人人为 在设计业务层流程时 robbin讲因该没错 如果其他模块。。。可能就。。。。。