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

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

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

 

DataAccessException extends RuntimeException  Dao层异常

ServiceException extends RuntimeException   Service层异常

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

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

 

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

 

评论

128 楼 ppgunjack 2011-03-20  

carlkkx 写道

ppgunjack 写道

乱吞异常用runtime可以解决吗？这是态度问题
乱吞至少不会崩，不抓，程序直接就挂了，放在生产环境直接就当了

乱吞是最严重的问题，你好好想想吧，掩耳盗铃和鸵鸟意味着什么？
你顶层需要有未处理异常捕获器，这是常识。

你不能理解每层都有自己的异常保护的含义，因为你是做桌面，对于在某层可恢复的概念没多少理解
未经预料到异常抛到预定之外的层和抛到最顶层的危害对于重要系统来说危害一样大，都是难以估计
如果你每层都catch那你runtime图什么，如果你不catch，你有本事预计哪些异常会捅上去吗，你有自信能在那么多调用中覆盖每个接口文档里说明可能会抛的异常而不让它乱窜吗？你相信你的文档能说明每个你可能抛出的异常和下级窜上来的异常吗？你相信每个你合做的同事用你库的和你用他们库的有这么严谨吗？

127 楼 carlkkx 2011-03-20  

乱吞异常用runtime可以解决吗？这是态度问题
————————————————
如果你不强迫别人，别人还发生乱吞现象，那这个人纯粹吃饱了撑的了？

126 楼 carlkkx 2011-03-20  

ppgunjack 写道

乱吞异常用runtime可以解决吗？这是态度问题
乱吞至少不会崩，不抓，程序直接就挂了，放在生产环境直接就当了

乱吞是最严重的问题，你好好想想吧，掩耳盗铃和鸵鸟意味着什么？
你顶层需要有未处理异常捕获器，这是常识。

125 楼 carlkkx 2011-03-20  

ppgunjack 写道

你要能理解美联储的作用就能知道资本主义社会对于市场什么叫自顶而下的管制
你找个保姆，保姆也会说我什么事情是不干的，你必须知道

晕倒，市场经济发展到今天，对人类历史的深刻影响又岂是之前严格的等级制度能比之的。你想说明什么，你的意思说社会主义其实比资本主义控制的少，社会主义才是自由社会？

124 楼 ppgunjack 2011-03-20  

乱吞异常用runtime可以解决吗？这是态度问题
乱吞至少不会崩，不抓，程序直接就挂了，放在生产环境直接就当了

123 楼 ppgunjack 2011-03-20  

你要能理解美联储的作用就能知道资本主义社会对于市场什么叫自顶而下的管制
你找个保姆，保姆也会说我什么事情是不干的，你必须知道

122 楼 carlkkx 2011-03-20  

倒是乱吞异常才会连未处理异常处理器都没抓到，可能倒是真的连日志都没有以及程序无声无息发生了无法到达预期的行为但没有错误报告出来。

121 楼 carlkkx 2011-03-20  

ppgunjack 写道

层层是指预料之内做可恢复性工作
如果没约束，仅仅你自己的疏忽，往上一通你在c层做的邮件通知，重连，记日志这些手段直接都跳过去，c层的异常控制逻辑已经完蛋了，直接就捅到了b，而b很可能没意识到居然会有个漏网的异常往上，因为c自己都没意识到，会写进文档吗
于是b也很可能牺牲，这就是一通到底
你做桌面，估计根本意识不到在某些层要做到可恢复和保护的重要性

你最顶层还是有未处理异常处理器，为什么会连记日志这些手段都没了？log中至少会记录发生了一个未处理异常，如果客户端软件那么可能会弹出，系统发生了一个错误，需要退出，。。。。，就像你用过微软的office肯定碰到过这种事吧，这种情况很明显系统发生了未预料的异常。

120 楼 ppgunjack 2011-03-20  

层层是指预料之内做可恢复性工作
如果没约束，仅仅你自己的疏忽，往上一通你在c层做的邮件通知，重连，记日志这些手段直接都跳过去，c层的异常控制逻辑已经完蛋了，直接就捅到了b，而b很可能没意识到居然会有个漏网的异常往上，因为c自己都没意识到，会写进文档吗
于是b也很可能牺牲，这就是一通到底
你做桌面，估计根本意识不到在某些层要做到可恢复和保护的重要性

119 楼 carlkkx 2011-03-20  

资本主义是市场经济但不是自由经济，该干预一样会强制干预，有些约束你一样必须遵守
——————————————————————
历史大量的时期处在严格的等级制度中，今天虽然不能说完全的自由市场经济（如同奥地利经济学派描述的那样），但是整个地球大多数地方都在进入市场经济，但是历史近几百年的发展远远超越前面千年万年的历史。这说明越复杂的系统采用越严格的自顶向下管制机制必然无法应对，极其落后。
从软件开发方法学上来说，瀑布模型的落后也是可见一斑。

118 楼 carlkkx 2011-03-20  

仅仅因为你自己的疏忽带来的上访会破坏层层已经做好的异常处理流程，
————————————————————————
这句话其实自相矛盾，既然你都层层已经做好异常处理，就是说明该处理的你处理了，那么上访的本来就是你这个层次无能为力的。

117 楼 ppgunjack 2011-03-20  

你别觉得你用别人的库，别人就是下级，你用电信的服务，电信条款也会写明出了问题我不付什么责任，你有什么问题你来保修

116 楼 ppgunjack 2011-03-20  

“API设计者没有资格要求调用者怎么处理错误”
这里不是API设计者要求调用者怎么处理错误，而是要求调用者接受通知，怎么处理还是调用者自己决定
就和发信的回执一样，重要的会强迫你发出回执，jms也有强制要求收到消息确认

115 楼 ppgunjack 2011-03-20  

底下的错误往上抛没问题
但问题在于你自己没控制住，底下也往上抛
形象的说就像上访，很可能你一个疏忽就直接到最上面，把你的上面，你上面的上面也弄崩
没有约束的含义就是你不注意，我就能越过你到你上面，你上面没意识到我能越过你没做保护我就可能通到你上面的上面
这个例子可能不恰当，因为这里的上访是会造成破坏性后果
仅仅因为你自己的疏忽带来的上访会破坏层层已经做好的异常处理流程，而这个疏忽显然不会被计入文档，因为根本没有约束，你自己都没意识到
这种破坏的可能性会随调用链的数目指数上升
资本主义是市场经济但不是自由经济，该干预一样会强制干预，有些约束你一样必须遵守

114 楼 carlkkx 2011-03-19  

ppgunjack 写道

API设计者没有资格要求？
那你用框架和回调不是典型的被api设计者要求
你用别人的库，别人很清楚的告诉你我提供服务的方式就是我做成你正常走，做不成我返回问题，你要接收，这是语言级别的约束，并且这是库设计者可以自己选择的哲学，你自己写完全可以绕过
灵活的代价就是容易出错，就像指针，这也是语言设计者的哲学，对于异常至少你还能绕过去，想要指针连门斗没有
js更灵活更没约束，写js代码比java更容易写错

你怎么单独领出这一句？这是回应另一个人的，指的是API设计者没有资格要求调用者怎么处理错误。你的模块要么完成你定义的任务要么向上报考问题，而不能指着上面说你一定要处理我或者你也一定要向像我这样声明强制你的上面，这是越权，你凭什么对着上面指手划脚，上面的场景你了解还是上面的使用者了解？

113 楼 carlkkx 2011-03-19  

ppgunjack 写道

carlkkx 写道

ppgunjack 写道

有checked你可以默认所有没异常申明的函数都是ok的，除了那些申明自己要抛的不用太关心那些没申明的
你使用api是不可能每个都去看文档的
我原来之所以会在dao采取这种方式因为我认为每个dao函数都应该有抛异常的可能，用check的话上层调用写起来太罗嗦，尤其再加个接口，实际spring的dao也是这样处理
而实际普遍考虑，大部分api是不应该我们操心问题的，如果有异常声明，则我们只用关注这些少量的问题点
如果全部都runtime那我们就要考虑每个调用可能造成的中断，每个api我都要参考它的文档关于异常的描述
另外一旦调用链拉长，a->d的文档是不会都那么全面和可靠，因为抛异常的可能性会随链的长度相乘

大多复杂性就是通过分而治之解决的，你非要担心你所面临的API以外的东西，那有什么办法呢？这样担心那就有太多担心了，这样的话，集成电路OK不OK那也是担心的。

依赖库调用的程序做异常设计是基于少数抛异常，多数不抛的原则设计
另外用文档来保证异常设计很天真，如果没有约束就连自己设计库都很难保证下层不会出乱子透过自己丢到上面，所有的异常都是runtime那么所有异常都可以有很大机会一直窜到根部调用，把你精心构建的异常层次搅得乱七八糟
我看你并不能很清楚的理解约束与自由的关系和它们带来的作用和副作用，也不能理解级联调用带来隐患的可能性随级联数目是乘法式的上升

如果在你这层上你确实不认为你可以处理什么，那么底下的错误往上抛又有何妨？这就是你要向上报告的问题。
底下如果是受检异常而你又确实认为你无能为力，这才是给你带来了麻烦。复杂性总是控制你和你的直接关系那一方，事情才能变得简单。越复杂越是松散的结构才能应对，好比社会是一个非常复杂的系统，有些人自以为聪明想搞计划经济，想自顶向下，结果反而一团糟，而市场经济更强调个人权利，看似没有控制却是无为而无不为。

112 楼 ppgunjack 2011-03-19  

API设计者没有资格要求？
那你用框架和回调不是典型的被api设计者要求
你用别人的库，别人很清楚的告诉你我提供服务的方式就是我做成你正常走，做不成我返回问题，你要接收，这是语言级别的约束，并且这是库设计者可以自己选择的哲学，你自己写完全可以绕过
灵活的代价就是容易出错，就像指针，这也是语言设计者的哲学，对于异常至少你还能绕过去，想要指针连门斗没有
js更灵活更没约束，写js代码比java更容易写错

111 楼 ppgunjack 2011-03-19  

carlkkx 写道

ppgunjack 写道

有checked你可以默认所有没异常申明的函数都是ok的，除了那些申明自己要抛的不用太关心那些没申明的
你使用api是不可能每个都去看文档的
我原来之所以会在dao采取这种方式因为我认为每个dao函数都应该有抛异常的可能，用check的话上层调用写起来太罗嗦，尤其再加个接口，实际spring的dao也是这样处理
而实际普遍考虑，大部分api是不应该我们操心问题的，如果有异常声明，则我们只用关注这些少量的问题点
如果全部都runtime那我们就要考虑每个调用可能造成的中断，每个api我都要参考它的文档关于异常的描述
另外一旦调用链拉长，a->d的文档是不会都那么全面和可靠，因为抛异常的可能性会随链的长度相乘

大多复杂性就是通过分而治之解决的，你非要担心你所面临的API以外的东西，那有什么办法呢？这样担心那就有太多担心了，这样的话，集成电路OK不OK那也是担心的。

依赖库调用的程序做异常设计是基于少数抛异常，多数不抛的原则设计
另外用文档来保证异常设计很天真，如果没有约束就连自己设计库都很难保证下层不会出乱子透过自己丢到上面，所有的异常都是runtime那么所有异常都可以有很大机会一直窜到根部调用，把你精心构建的异常层次搅得乱七八糟
我看你并不能很清楚的理解约束与自由的关系和它们带来的作用和副作用，也不能理解级联调用带来隐患的可能性随级联数目是乘法式的上升

110 楼 carlkkx 2011-03-19  

喜欢checkedException多是自以为是。喜欢替别人乱作决定，失去基本权利观的认知。

109 楼 carlkkx 2011-03-19  

qianhd 写道

好好的帖子 就被carlkkx搞的乱七八糟
MS的设计思想是啥?
就是让普通的程序员 通过MSDN的例子就能写出代码
全部都用RuntimeException只不过是对乱吞异常的妥协
但是不能因为妥协了 就说checkedException不好

James Gosling 的设计和层次 是你能理解的了的吗?


对于这213的帖子 没必要再回了
还不如看以前的精华帖 探讨的层次高多了
http://www.iteye.com/topic/2038

你以为你就了不起了，还看不起别人，你以为在MS平台做开发的人就比你弱？反对checkedException的大牛也有的是，请问这些人的层次又是你能理解的吗？