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

额。。那你catch他干啥呢。。直接不catch不就结了。

如果是Checked Exception 那么你会被强迫要干点什么，不是catch就要声明。这种强迫在理念上本根就是错误的。

业务中如果能够从某种错误中恢复，或者需要业务处理某种错误时，这时候就应该抛出受检异常！

为什么理念上就不对？
我的理解是：
Checked Exception明确的告诉编码人员，在执行某个调用时，有可能产生什么样的特殊情况
未知的错误才是最可怕的
能够有一种机制，提醒你去处理该处理的情况，总比出了问题都不知道怎么回事好的多

难道你写代码的时候，都指望只写主成功场景？

这里的根本错误就是你怎么知道你的上层就一定能处理你？作为API的提供者你的责任无非就是阐明我会抛出哪些异常，而调用者在哪个层面上处理你这是由调用者决定的。而现在Checked Exception武断的强制调用者必须要怎样怎样。这还不是理念上的问题？可能调用者明明觉得在他这一层次上无法处理这个异常，但是被你Checked Exception强迫他不得不再往上声明异常，或者不懂得人干脆直接乱catch打印一下。唯有一招就是捕获后再变成运行时异常往上抛，目前很多开源框架就是这么做的，要是当初Java标准库没有那么多Checked Exception哪里还需要这么做。

不管能不能恢复或如何那都是调用者的事，作为你的模块你抛出异常就说明处于某种原因你已经无法完成任务，你报考异常你的职责就已经完成了，你还武断的认为你的调用者一定要怎么怎么样这是理念上的错误，调用者在哪个层面上处理你由他那边的考量，作为抛出异常的那一方本根不应该武断的认为如何如何。如果我是调用者而又发现这我这个层面上我是无法处理的，使用检查异常的API我会很难受。

Checked Exception 根本错误是让抛出异常那一方自作聪明，强制调用者必须怎么怎么样，这是职责不清，自作聪明。

所以我们真正需要的只是告知，即API的说明而已，异常也是API接口的一部分。注意仅仅是告知，但是Checked Exception违背了仅仅告知的原则而是在编译检查上做了很多强制，大量的乱吞异常由此产生。

从现实角度，即使是Java领域Checked Exception也越来越少使用，这说明Checked Exception是个失败的设计一点也不为过了。
C#在很多语言设计上都是超过Java的，异常这件事上也是如此。

这不扯淡么，RuntimeExcepton是非常理想的捕捉对象。
如果自定义异常比较明确的话，把checkexception转成RuntimeException可以减少很多“throws”。
另外，配置错误不一定是程序员的错，许多大系统是由实施人员来实施的，你如何避免配置错误？避免不了就需要捕捉，抛出RuntimeException后可以用自定义异常处理机制来给用户明确的提示