老掉牙的话题，java的异常处理。

我设计是整个平台只抛一个异常，DAO自动抛runtime的异常，到service统一捕获，到web统一处理一个异常。。。

checked excetpion， 对于确实需要处理的异常， 可以明确在编译期间就告诉方法调用者，并且强制让其能做合适的处理，这种情况还是有用的。但是如果异常没法处理，也采用
checked excetpion，就会导致异常没正确处理或者层层往外throws，这时又显得没必要，而且让代码显得很难看。反之这种情况采用unchecked就比较合适。
checked excetpion，大部分人都会catch，然后简单打印，异常就被吞了；unchecked，因为不会显式throws，也不会强制要求处理，眼不见为净，代码清静许多，只需要做一个统一异常处理层面，对unchecked来个统一性的处理，其实也只要告之操作者系统出错了。
看起来是checked和unchecked是都有各自的优缺点，有适合各自的应用场景，结合它们的优点来用也应该是可以的。但如果非要做取舍，个人的倾向，干脆就将异常全设计成unchecked的好了。分两类，需要关注的就叫做ServiceException， 对ServiceException进行业务编号， 代码中捕获ServiceException，根据编号进行业务处理；另外一类，就都当成是系统出错了，交给统一异常处理层了。

checked excetpion， 对于确实需要处理的异常， 可以明确在编译期间就告诉方法调用者，并且强制让其能做合适的处理，这种情况还是有用的。
——————————————————————————
确实不确实这件事是调用者确定的而不是你这边确定的，如果你认同这个理念那么checked excetpion就是个错误的设计。它赋予了抛出异常方滥用权力，最终导致强暴很多调用者。

这种强暴导致了最后调用者本根不鸟他，直接吞了了事。

这个接近我现在做系统的异常处理方案。只不过我这里dao层封装了DataAccessException，然后统一捕获报告数据库错误。

RuntimeException的意思是：当程序遇到这种异常时是不可恢复的，程序应该终止了，所以捕获这种异常没有意义。一般是最外层程序捕获它，记录日志，发送邮件。

谁这么定义RuntimeException的意思的？完全是胡说，最顶层捕获到未处理异常才应该终止了（当然这也不是一定的）。

这里核心点是未处理异常而不是什么RuntimeException，RuntimeException完全有可能被捕获以及被处理。

当a库依赖b库，你调用a库，如果b库全是RuntimeException，并且你拿不到b库文档，你用a库能写出健壮的代码是不可能的，你自己精心构建的异常处理逻辑能轻松被无法预见的RuntimeException打断，因为你预计不到a库什么时候会被b库的雷给牵连，任何对a的调用都要考虑可能由b导致的连环雷
把代码比作做事，RuntimeException就相当于天灾人祸，意外之外的，至于发生了你愿意自己继续干还是终止取决于你自己意愿
而checked就是说你需要弄清楚并且汇报给上级那些是问题，那些是你会遇到但你解决不了的，但都是你意识到的问题，别人让你做事，你要给别人说好，如果让我干可能出现意外1，2，3，怎么处理你自己决定

调用链是a->b->c->d，如果d是没任何这种提前约定的契约，那么a要操心的就是调用b的所有接口，b随时也有可能被c的调用打断，而c随时会被d打断，看似编码简单，实际异常处理被大幅扩大

最简单的例子，你老板让你干活都需要先分析风险，你可能会让底下再分析，然后汇报，然后才是每层自己根据汇报的风险制定计划和执行

如果全unchecked相当于你没任何汇报，只是告诉上级，你让我干事有风险，干什么事都有风险也可能都没风险，你分配我任务的时候自己看着办，还有我下属的风险我可能也转给你也可能不给你我自己搞定，这看我自己风格，你也自己看着办吧

你只跟a有关系，如果a的描述中没有那是a的问题，照你这么说你做每一件事都是寻根问底，否则就不存在安全性了，那封装就没有意义了，因为每一层API你都要看到底，否则你心中没有底。

异常的出现就是因为入力的条件不符合要求， 不能正确为客户返回正确的结果。 造成这种现象的原因是无法从编译程度上限制 入力条件完全满足自己的需求。

个人觉得Runtime exception和check exception的区别是。
check exception： 程序级不可控的异常，是因为终端用户的原因或者物理环境的原因导致的。 所以这些异常要一层层往上抛， 最终发给终端用户。  这样处理的目的是为了给上层的调用者忽略异常的机会。 告诉调用者你发给我的这些条件， 可能存在这样的问题， 如果出现这样的问题， 需要你处理一下。
Runtime exception： 程序级可控的异常。 这些基本和终端用户没啥关系。 基本是因为程序员编码失误造成的。 所以直接抛出运行时异常，终止系统运行。 （当然真正运用的时候，会在用户最初始的调用方法的地方捕获所有的异常，不会真正让系统挂掉）。

所以，个人感觉对于异常设计的初衷是（自己想的）： 对于用户的错误， 那么需要用户去检查， 所以一层层抛出，最终抛给用户。
而对于运行时异常， 则直接挂掉整个系统， 让程序员来重新修改系统。