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

关于系统中的异常怎么处理，之前也看过很多的文章。只是觉得越看越糊涂，大家持很多不同的意见。

现在想形成一套自己的观点，合自己口味的解决方案。没有对与不对，因人而宜。

 

DataAccessException extends RuntimeException  Dao层异常

ServiceException extends RuntimeException   Service层异常

我被java的RuntimeException和Exception的使用一直弄得头晕。
现在的观点是，把Exception转化成RuntimeException，省的方法还throws，个人觉得的throws看起来不爽，呵呵。
这就相当于在自己写代码过程中放弃了使用Exception。减少烦恼

但是有些自己写的工具类当中又是怎么处理呢。抛还是不抛（通过返回值），抛什么？

 

欢迎大家发表下意见，批评改正。

 

评论

168 楼 carlkkx 2011-03-20  

ppgunjack 写道

Bruce Eckel，论文正在看
没有约束很容易带来runtime的意外抛出和文档缺失，这些对于优秀开发者问题严重比菜鸟低，但一样是问题，就和指针一样，并且在构建可恢复应用当中，这些约束的重要性超出你目前的认知能力
不打算争吵，你只能看问题一面，并且也不准备尝试思考问题的另一面

其实checkedException到了菜鸟那边产生的问题很严重，那就是乱吞异常，checkedException何曾达到了它要达到的目的？
而runtimeException通过我说的倒追法，最后的效果绝对好于乱吞异常。

167 楼 carlkkx 2011-03-20  

checkedException尤其像本朝公仆，表明上看起来是更多为人民服务，很积极，手伸得很长，替人民做事，规定人民必须这个必须那个，不给人民更多选择的理由和checkedException差不多，因为那样会乱的。其实殊不知你是纳税人养你的，你是服务方，你怎么对使用服务的人指手划脚了，这还是服务者的心态吗？怪不得服务方有些人喜欢checkedException，因为这会有当领导的感觉，有哥说了算的感觉。结果苦了调用方。

166 楼 ppgunjack 2011-03-20  

Bruce Eckel，论文正在看
没有约束很容易带来runtime的意外抛出和文档缺失，这些对于优秀开发者问题严重比菜鸟低，但一样是问题，就和指针一样，并且在构建可恢复应用当中，这些约束的重要性超出你目前的认知能力
不打算争吵，你只能看问题一面，并且也不准备尝试思考问题的另一面

165 楼 carlkkx 2011-03-20  

其实checkedException是典型的公仆变官老爷变领导，本来你一个服务方，你无非就是完成你定义的服务，完成不了报告相应的问题，说明你可能发生的问题。能做到这样这就是很好很好的服务者了，可偏偏你的手脚伸长了，你要决定使用服务的人必须处理我这个那个可能的问题，这个选择权是使用服务的人的，不是你的。你的权利义务本来已经定义的很清楚了，你不该侵犯使用服务那一方的选择权。

164 楼 carlkkx 2011-03-20  

ppgunjack 写道

unchecked异常和回调，消息框架和接口契约一样，是种机制，既然是机制当然有侵入性和约束性
辩证也不是max才有的认识，西方管这叫客观，去发现事物存在的两面性
我说的你不懂，问题回答了你也以为没有回应，我知道的也都尽量以最简单的形式表达了，至于你能懂多少那要看你自己接受能力

还西方，西方的谁啊，老马也是西方的，你的意思 辩证=客观？并且这是西方的观点而不知哪方的老马（难道是东方）管着叫辩证。
我不知道你回答什么，如果非要有那就是你类似这样的陈述：破坏契约有时候必要的，侵权有时候是必要的，因为那是服务方替调用者着想，关心调用者，调用者都是弱者是温室的花朵，他们不应该有选择权，服务方是人民公仆，为人民服务，人民不应该有选择权。

163 楼 ppgunjack 2011-03-20  

unchecked异常和回调，消息框架和接口契约一样，是种机制，既然是机制当然有侵入性和约束性
辩证也不是max才有的认识，西方管这叫客观，去发现事物存在的两面性
我说的你不懂，问题回答了你也以为没有回应，我知道的也都尽量以最简单的形式表达了，至于你能懂多少那要看你自己接受能力

162 楼 carlkkx 2011-03-20  

Bruce Eckel其实已经声明：
在使用 Java 语言多年后，他已经得出这样的结论，认为检查型异常是一个错误 —— 一个应该被声明为失败的试验。

161 楼 carlkkx 2011-03-20  

checkedException原先在Java中是正统地位的，如今呢？尽管它当然是存在的，但是他已经是配角了，而且我认为更往后会更边缘化，Java标注库中大量的checkedException使用，带来了非常多的麻烦，但是这些API很多都是在checkedException是正统地位时设计的。这是历史预留问题了。

160 楼 carlkkx 2011-03-20  

ppgunjack 写道

就是Java阵营曾经那些拥护者很多估计也幡然醒悟了，比如《Think in Java》的作者。 ？？？

他是c++出身，你看看他怎么评价java异常吧
java异常是有瑕疵，这本书里面也说了，但不是针对unchecked还是checked

你要看看他的转变，Bruce Eckel 和 Rod Johnson这些都转变了，Bruce Eckel应该转的更为彻底。

159 楼 carlkkx 2011-03-20  

ppgunjack 写道

引用

checkedexception产生的问题远远比对他的预期要多
因为你没有顶层未处理异常捕获器的习惯，所以你甚至不能理解或体会我说的倒追法。

我说的已经很浅显了，checkedexception显然不是弊大于利的东西，更不是一无是处
你如果不懂辩证看这个问题说明遇到问题还不够多

老马的哲学观我不鸟，所以不要和我说什么辩证，反正辩证是万精油。
你的显然是怎么来的。没有基础的显然。你至始至终没有正面回应我上面说了很多的契约式，权利观这些。

158 楼 ppgunjack 2011-03-20  

就是Java阵营曾经那些拥护者很多估计也幡然醒悟了，比如《Think in Java》的作者。 ？？？

他是c++出身，你看看他怎么评价java异常吧
java异常是有瑕疵，这本书里面也说了，但不是针对unchecked还是checked

157 楼 ppgunjack 2011-03-20  

引用

checkedexception产生的问题远远比对他的预期要多
因为你没有顶层未处理异常捕获器的习惯，所以你甚至不能理解或体会我说的倒追法。

我说的已经很浅显了，checkedexception显然不是弊大于利的东西，更不是一无是处
你如果不懂辩证看这个问题说明遇到问题还不够多

156 楼 carlkkx 2011-03-20  

Java基本可以说是唯一个采用checkedexception的主流语言，如果它是一个优秀特性一个好的思想，怎么会弄来如此大的反对声，如此大的争议，别的语言可能早就竞相模仿了。还会受如此的冷落。垃圾回收是个好东西所以大量语言都支持，而checkedexception是一次失败的尝试。这个在我看来已经尘埃落定。

155 楼 carlkkx 2011-03-20  

你先把那个帖子好好看一遍再说
————————————
我看了，这个帖子很早，那时这个争端可能还是比较火热的时候，从Java阵营来说拥护checkedexception可能还很多，但是时至今日别说其他阵营了，就是Java阵营曾经那些拥护者很多估计也幡然醒悟了，比如《Think in Java》的作者。

154 楼 carlkkx 2011-03-20  

我原来做开发是不会在根部catch任何runtime的异常，意料之外的runtime都是会直接导致当机
因为这如果发生代表我的代码出现了我完全没想到的问题，既不在主流程也不在预计内的异常流程
这个异常突破了所有异常处理和保护来到main，那么调用链涉及的下面的component因为这个异常导致的问题和后续可能造成的影响我无法估计，因为每个调用都只跑了不确定的半截，这个时候不如停下来，保证破坏不会被扩大，当然这种设计不一定会被接受，尤其国内，也不适合所有系统
实际上根调用加个catch all易如反掌，但异常真的到了这步，其实这个应用就像内部已经出了一系列故障的飞机，你只是视而不见，却仍然让他继续飞
————————————————————
这是你的问题，无论如何你都应该尽力不能让系统无声无息的完蛋，即使完蛋了，也要告知我完蛋了，如果你没有顶层未处理异常捕获器，你就没有这个机会。你看过很多软件即使完了，他也会告知你，有些还可能让你发送错误报告等等。照你这么弄的话直接就无声无息崩溃了。
因为你没有顶层未处理异常捕获器的习惯，所以你甚至不能理解或体会我说的倒追法。

153 楼 carlkkx 2011-03-20  

carlkkx 写道

ppgunjack 写道

你先把那个帖子好好看一遍再说
我告诉你，软件设计和现实一样有很多是基于契约，就像合同的甲方乙方，都可能存在互相侵入的条款,而且有时这是必要的，或者说有保护性的
脑子别那么死，这是那个帖子的一个回复，发帖的也应该是很有经验的开发者

引用

I favor RuntimeException too.

But, sometimes, I do miss checked exception when I forget to catch an exception that's supposed to be handled, or forget to "throws" a runtime exception (for documentation reason)

增加一个约束往往要增加不少成本，你应该多考虑设计者增加这个成本到底是用来解决什么问题
在那个帖子也有提到框架喜欢抛unchecked一个原因是因为框架异常实际客户代码根本搞不定，这样很多时候就不存在在某层恢复的可能性，这使得框架异常经常需要一直捅上去，所以check这时是种阻碍
但你构建自己的应用并不是这样，你这个层次搞不定的问题，可能必须要上面某一层搞定，所以安全的途径是通过固化机制强制执行

我原来做开发是不会在根部catch任何runtime的异常，意料之外的runtime都是会直接导致当机
因为这如果发生代表我的代码出现了我完全没想到的问题，既不在主流程也不在预计内的异常流程
这个异常突破了所有异常处理和保护来到main，那么调用链涉及的下面的component因为这个异常导致的问题和后续可能造成的影响我无法估计，因为每个调用都只跑了不确定的半截，这个时候不如停下来，保证破坏不会被扩大，当然这种设计不一定会被接受，尤其国内，也不适合所有系统
实际上根调用加个catch all易如反掌，但异常真的到了这步，其实这个应用就像内部已经出了一系列故障的飞机，你只是视而不见，却仍然让他继续飞

你所说的无非就是强暴和乱吞，当老板让你你做事你事先向老板提要求和明确风险措施的时候，你认为这也是强暴吗？这就叫事前报告，让调用者做充分准备，如果你的老板是个天才无所不知无所不记，自然这个报告和流程是不必要的

我说的对你来说你现在也不可能理解，逐渐体会吧

你既然讲到契约，你却为什么不能体会这段话呢：
我对checkedException 非常的反对，非常的不喜欢，不仅仅是什么过于学院化不实用之类的，而是从理念上认为它是错误的，因为它颠倒了权利关系。
处理什么错误的选择权是调用者的，而不是被调用方的，API方只有说明权不能侵犯调用者的选择权。因为你是服务的一方，你居然干涉用户的的选择，你强买强卖。这完全是对调用方的侵权行为。

你当然有说明权和报告权，甚至这是你的责任，但是你没有强制调用方对错误处理的选择权。

而且失败的理念必然导致失败的实践，checkedexception产生的问题远远比对他的预期要多，C#写的程序质量就比java差？
比开发高质量软件能和Eiffel比吗，Eiffel为什么是高质量恰恰是因为其严格契约式理念。checkedexception是混淆职责，而不是清晰职责。

152 楼 carlkkx 2011-03-20  

ppgunjack 写道

你先把那个帖子好好看一遍再说
我告诉你，软件设计和现实一样有很多是基于契约，就像合同的甲方乙方，都可能存在互相侵入的条款,而且有时这是必要的，或者说有保护性的
脑子别那么死，这是那个帖子的一个回复，发帖的也应该是很有经验的开发者

引用

I favor RuntimeException too.

But, sometimes, I do miss checked exception when I forget to catch an exception that's supposed to be handled, or forget to "throws" a runtime exception (for documentation reason)

增加一个约束往往要增加不少成本，你应该多考虑设计者增加这个成本到底是用来解决什么问题
在那个帖子也有提到框架喜欢抛unchecked一个原因是因为框架异常实际客户代码根本搞不定，这样很多时候就不存在在某层恢复的可能性，这使得框架异常经常需要一直捅上去，所以check这时是种阻碍
但你构建自己的应用并不是这样，你这个层次搞不定的问题，可能必须要上面某一层搞定，所以安全的途径是通过固化机制强制执行

我原来做开发是不会在根部catch任何runtime的异常，意料之外的runtime都是会直接导致当机
因为这如果发生代表我的代码出现了我完全没想到的问题，既不在主流程也不在预计内的异常流程
这个异常突破了所有异常处理和保护来到main，那么调用链涉及的下面的component因为这个异常导致的问题和后续可能造成的影响我无法估计，因为每个调用都只跑了不确定的半截，这个时候不如停下来，保证破坏不会被扩大，当然这种设计不一定会被接受，尤其国内，也不适合所有系统
实际上根调用加个catch all易如反掌，但异常真的到了这步，其实这个应用就像内部已经出了一系列故障的飞机，你只是视而不见，却仍然让他继续飞

你所说的无非就是强暴和乱吞，当老板让你你做事你事先向老板提要求和明确风险措施的时候，你认为这也是强暴吗？这就叫事前报告，让调用者做充分准备，如果你的老板是个天才无所不知无所不记，自然这个报告和流程是不必要的

我说的对你来说你现在也不可能理解，逐渐体会吧

你既然讲到契约，你却为什么不能体会这段话呢：
我对checkedException 非常的反对，非常的不喜欢，不仅仅是什么过于学院化不实用之类的，而是从理念上认为它是错误的，因为它颠倒了权利关系。
处理什么错误的选择权是调用者的，而不是被调用方的，API方只有说明权不能侵犯调用者的选择权。因为你是服务的一方，你居然干涉用户的的选择，你强买强卖。这完全是对调用方的侵权行为。

你当然有说明权和报告权，甚至这是你的责任，但是你没有强制调用方对错误处理的选择权。

151 楼 ppgunjack 2011-03-20  

你先把那个帖子好好看一遍再说
我告诉你，软件设计和现实一样有很多是基于契约，就像合同的甲方乙方，都可能存在互相侵入的条款,而且有时这是必要的，或者说有保护性的
脑子别那么死，这是那个帖子的一个回复，发帖的也应该是很有经验的开发者

引用

I favor RuntimeException too.

But, sometimes, I do miss checked exception when I forget to catch an exception that's supposed to be handled, or forget to "throws" a runtime exception (for documentation reason)

增加一个约束往往要增加不少成本，你应该多考虑设计者增加这个成本到底是用来解决什么问题
在那个帖子也有提到框架喜欢抛unchecked一个原因是因为框架异常实际客户代码根本搞不定，这样很多时候就不存在在某层恢复的可能性，这使得框架异常经常需要一直捅上去，所以check这时是种阻碍
但你构建自己的应用并不是这样，你这个层次搞不定的问题，可能必须要上面某一层搞定，所以安全的途径是通过固化机制强制执行

我原来做开发是不会在根部catch任何runtime的异常，意料之外的runtime都是会直接导致当机
因为这如果发生代表我的代码出现了我完全没想到的问题，既不在主流程也不在预计内的异常流程
这个异常突破了所有异常处理和保护来到main，那么调用链涉及的下面的component因为这个异常导致的问题和后续可能造成的影响我无法估计，因为每个调用都只跑了不确定的半截，这个时候不如停下来，保证破坏不会被扩大，当然这种设计不一定会被接受，尤其国内，也不适合所有系统
实际上根调用加个catch all易如反掌，但异常真的到了这步，其实这个应用就像内部已经出了一系列故障的飞机，你只是视而不见，却仍然让他继续飞

你所说的无非就是强暴和乱吞，当老板让你你做事你事先向老板提要求和明确风险措施的时候，你认为这也是强暴吗？这就叫事前报告，让调用者做充分准备，如果你的老板是个天才无所不知无所不记，自然这个报告和流程是不必要的

我说的对你来说你现在也不可能理解，逐渐体会吧

150 楼 carlkkx 2011-03-20  

我不知道大家是否看懂了我上面描述的权利关系，我认为很容易明白，如果你认同这个权利关系，那么checkedException的使用必然存在侵权行为。

149 楼 carlkkx 2011-03-20  

我对checkedException 非常的反对，非常的不喜欢，不仅仅是什么过于学院化不实用之类的，而是从理念上认为它是错误的，因为它颠倒了权利关系。
处理什么错误的选择权是调用者的，而不是被调用方的，API方只有说明权不能侵犯调用者的选择权。因为你是服务的一方，你居然干涉用户的的选择，你强买强卖。这完全是对调用方的侵权行为。