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

算了，你既然runtime先天就是有可忽略特性，你的调用者忽略你的可能性远大于checked
显然你认为911和110不是被用来强制接受异常，你以后就打10086吧，回追也能帮到你的

认识差距太大，你说的我没啥不懂，我说的你一概不听，这个问题没多少我还需要思考和澄清的，到此为止

补充一点，
checked异常应该在确认调用者应该予以解决的地方抛出，也就是说checked应该代表着要求在最近的某个层可恢复，这个异常应该尽量在靠近抛出点被解决和消化，因为只有最近的几层才最有恢复的可能，抛到最上层很多现场和引用已经失效，除了log对于恢复已经毫无能力，那此时checked不如转义为unchecked更为方便

不是不听，听了，只是我不认同。因为我始终坚持考虑有什么危险的问题是调用者的责任，服务方做到各种告知责任已到。
而你做了一个假设，如果不强制的话，一定会一桶到顶，即调用者是不思考的，调用者一定会犯错，我一定要保护他们。而这种强制可能恰恰产生问题，因为你忘了你也会犯错，你很可能做了你认为确定但是是错误的强制。

其实你的这种理念和本朝的口吻有相似之处，比如很多领域不开放市场由央企独家垄断，本朝是怎么解释的呢？大致是这样的：这些行业关乎国计民生，所以不能开放，只有在D和ZF的领导下才能有序的运行，否则一定会造成。。。。。。此处省略很多字。

我又想了一下，发现你的理念来源于长期处于checkedException之后造成，checkedException造成的职权关系错论导致长期处于这种理念下的人存在错误的依赖症，即明明应该是调用者要做的决定，明明应该是调用者的责任，明明应该是要调用者有的主见，统统没了，统统变成服务方应该要预先想好，使得调用者完全变成依赖者，连你应该要捕捉哪些异常服务方都替你决定了。当我们批评checkedException时，持有错误依赖症的人会突然觉得不可思议，但是实际上这本根就是用错误世界里面的错误依赖症去看待一个正常权利关系的世界。
好比在市场经济之前，很多人担心市场经济导致混乱一样，这本根就是用一个之前世界里面的错误观点去硬套另一个世界。

人服务于社会，一个作为社会一员的服务方的小角色正企图以服务方不应该干涉调用方的理论来干涉社会这个调用方的工作逻辑，真是个悖论

我不认为有什么悖论，而是一个平等权利关系的划分问题，你把所有的责任都推给服务方，连调用方要捕捉哪些异常都给决定了，这也类似父母溺爱孩子，造成本该孩子的责任都不存在了，权力关系发生错乱后，必然形成一个一边倒的依赖症。而不是权力责任自洽的完整体。

标准答案是
用CheckedException
业务层抛出一个通用的基类Exception
这个exception只在程序出现无法恢复的异常采用，数据之类可恢复的异常一概不用exception
业务层无论产生或不产生exception都需要声明throws exception

理由如下
1.业务经常变化，exeption太多将来改不起
2.这类异常都交由特定类处理，业务层不处理，直接throw就好
3.uncheckedexeption需要开发人员有比较高的技巧，而且不易于维护。可能是个很优雅或者很方便，但是现今中国不实用
4.这个属于design by contract的一部分，以后自己去翻相关文档即可

回过头来看看，我更坚信自己的看法，程序员需要的是方便的异常说明机制而不是编译级别的强制。

我认为，异常如此混乱的根源，在于允许new一个异常
我的观点是，语言级别上就不应该能够new异常，所有异常只能jvm抛出，最常见的就是空指针异常了