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

对于自己知道该怎么处理的异常, 就在catch子句做相关操作, 然后根据必要选择抛出会不抛出. 对于自己不知道该怎么处理的异常, 接着往上抛就是了

runtime exception不强制catch是好的，但是不强制throws，写代码的时候怎么办？所有的调用都try？那即没效率，又难看

checkexception强迫我不能处理的要进行runtimes包装再抛，应该是这样才对，用户（调用者）选择他认为要处理的，不处理本根不需要做额外的动作。

注释当中写明你可能抛出的异常就可以了，让使用者选择处理还是不处理而不是你强制决定。

实际上我觉得真正需要的是一种便捷的说明方式而不是编译级别的强制。

总之，checkexception带来问题一定比runtime exception问题多，这估计也是实践证明了的。

我所强调不是“配置出错到底是不是程序员错”的问题，而是CheckedException异常无法避免，RuntimeExcepton异常可避免的问题，如果一个异常程序员无法避免其发生，就应该考虑把它设计成CheckedException，强迫api的使用者处理异常。而一个RuntimeException，比如NullPointException，难道你发现你写的程序运行时抛出了一个NullPointException,你在debug的时候，难道是直接去catch这个异常，而不是在引用空指针变量的时候做判断？

需要处理的捕获后处理

不需要处理的直接抛出直到顶层，统一处理记入日志或者返回到界面

我自己写的程序不用CheckedException是因为我分不清什么情况下用。不排除java的CheckedException给编码带来了好处，比如有些异常在编译期间就提醒你捕获处理，而C#在你不了解某个方法抛出异常的情况下在运行期间发生了错误，而你又要回过头就查找处理。

估计CheckedException最初的设计意图是，系统每一个地方的问题都被处理过了，则系统就是安全稳定的了。CheckedException则给服务代码一次强暴"客户代码必须注意任何可能情况"的机会。可是他忽略了一个问题，接口的膨胀导致代码的可读性很差，没有经验的程序员或者匆忙的程序员不知道是该继续抛出，还是该怎么处理，所以这样看来，CheckedException给了服务代码强暴客户代码机会的同时，也给了没有经验或者匆忙的程序员一个搞砸问题的机会。