http://www.iteye.com/topic/2038?page=1
一个很好的讨论贴。
-------------------
使用Checked Exception还是UnChecked Exception的原则，我的看法是根据需求而定。
如果你希望强制你的类调用者来处理异常，那么就用Checked Exception；
如果你不希望强制你的类调用者来处理异常，就用UnChecked。
那么究竟强制还是不强制，权衡的依据在于从业务系统的逻辑规则来考虑，如果业务规则定义了调用者应该处理，那么就必须Checked，如果业务规则没有定义，就应该用UnChecked。
还是拿那个用户登陆的例子来说，可能产生的异常有：
IOException (例如读取配置文件找不到)
SQLException (例如连接数据库错误)
ClassNotFoundException(找不到数据库驱动类)
NoSuchUserException
PasswordNotMatchException
以上3个异常是和业务逻辑无关的系统容错异常，所以应该转换为RuntimeException，不强制类调用者来处理；而下面两个异常是和业务逻辑相关的流程，从业务实现的角度来说，类调用者必须处理，所以要Checked，强迫调用者去处理。
在这里将用户验证和密码验证转化为方法返回值是一个非常糟糕的设计，不但不能够有效的标示业务逻辑的各种流程，而且失去了强制类调用者去处理的安全保障。
至于类调用者catch到NoSuchUserException和PasswordNotMatchException怎么处理，也要根据他自己具体的业务逻辑了。或者他有能力也应该处理，就自己处理掉了；或者他不关心这个异常，也不希望上面的类调用者关心，就转化为RuntimeException；或者他希望上面的类调用者处理，而不是自己处理，就转化为本层的异常继续往上抛出来。
--------------------
异常类层次设计的不好带来的结果就是非常糟糕，例如JTA的异常类层次，例如EJB的异常类层次，但是也有设计的很好的，例如Spring DataAccessException类层次结构。
用设计糟糕的异常类层次来否定异常这个事物，是极度缺乏说服力的，就好像有人用菜刀砍了人，你不能否定这把菜刀一样。
这个帖子这么长了，该讨论的问题都讨论清楚了，总结也总结过n遍了，所以我早就没有兴趣再跟帖了。
实际上，这个讨论中隐含两个不断纠缠的话题：
1、checked ，还是unchecked异常？
2、用自定义的方法调用返回code，还是用异常来表达不期望各种的事件流
经过这么长的讨论，我认为结论已经非常清楚：
1、应该适用unchecked异常，也就是runtimeexception，这样可以让无法处理异常的应用代码简单忽略它，让更上层次的代码来处理
2、应该适用异常来表达不期望的各种事件流
事实上，你们去看一下现在Spring，Hibernate3都已经采用这种方式，特别是Spring的DataAccessException异常层次设计，是一个很好的例子。即使用RuntimeException来表达不期望的各种事件流。
----------------------------------------
---------------------------------------------------------------------
常见的runtimeexception:
- NullPointerException - 空指针引用异常
- ClassCastException - 类型强制转换异常。
- IllegalArgumentException - 传递非法参数异常。
- ArithmeticException - 算术运算异常
- ArrayStoreException - 向数组中存放与声明类型不兼容对象异常
- IndexOutOfBoundsException - 下标越界异常
- NegativeArraySizeException - 创建一个大小为负数的数组错误异常
- NumberFormatException - 数字格式异常
- SecurityException - 安全异常
- UnsupportedOperationException - 不支持的操作异常