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

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

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

 

DataAccessException extends RuntimeException  Dao层异常

ServiceException extends RuntimeException   Service层异常

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

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

 

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

 

评论

28 楼 carlkkx 2011-03-17  

别人被强暴的多了，基本就是掩耳盗铃的乱吞异常，所以强暴带来的问题比它解决的多。

27 楼 carlkkx 2011-03-17  

checkexception本根就是武断行为，自以为是的行为，喜欢强迫别人的行为，职责不清。

26 楼 carlkkx 2011-03-17  

一下想到 checkexception的人就是喜欢瞎操心，喜欢替调用者想事情，喜欢强迫调用者怎么样。人家调用你的人到底怎么想的你无法武断定义的，你管好你自己模块就好了，你只要说清楚我正常怎么样错了怎么样就行了，怎么处理这件事你不能武断定义。

25 楼 carlkkx 2011-03-17  

Jazag.van 写道

如果全是runtime exception你不catch，有些回滚操作怎么办？

catch不catch是调用者的事，你把异常说清楚就行了。难道runtime exception就不能catch了？

24 楼 Jazag.van 2011-03-17  

如果全是runtime exception你不catch，有些回滚操作怎么办？

23 楼 carlkkx 2011-03-17  

qianhd 写道

carlkkx 写道

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

乱吞异常的产生很大的原因是eclipse默认的处理方式
就是点红点的修改提示
这样一来 不懂的人就会随意的吞异常

虽然连续向上的throws exception非常的不友好,
但如果只有Runtime exception, 经常会忘记处理异常,直到测试发现,或者用户发现问题.

统一处理的话又缺乏恢复机制

照你这样throw下去，方法的接口都成什么样子了。。。。。。。。。

22 楼 ppgunjack 2011-03-17  

spring dao封装excpetion是不用捕捉，我也这样做过
感觉如果自己内部就能消化这没什么问题，但如果是面向对方的服务，应该清楚告诉对方正常怎样，不正常怎样，什么异常会抛出来，就和合同一样，这本身就应该是函数调用的定义契约
不能别人觉得好好的，突然丢个出去，造成一堆调用中断

21 楼 qianhd 2011-03-17  

carlkkx 写道

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

乱吞异常的产生很大的原因是eclipse默认的处理方式
就是点红点的修改提示
这样一来 不懂的人就会随意的吞异常

虽然连续向上的throws exception非常的不友好,
但如果只有Runtime exception, 经常会忘记处理异常,直到测试发现,或者用户发现问题.

统一处理的话又缺乏恢复机制

20 楼 carlkkx 2011-03-17  

fangin 写道

kevin1988620 写道

我的处理的原则是，只捕捉checkexception,而忽略RuntimeException。
RuntimeExcepton的产生是程序员的责任，如配置文件写错，空指针引用等。应该是避免这样的异常发生，而不是发生后捕捉处理它。
CheckedException是程序员无法避免的，比如用户的非法输入，非法点击等。这样的异常既然没办法避免，就只能等它发生后再捕捉。

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

支持，kevin1988620说的基本都是错的。

19 楼 fangin 2011-03-17  

kevin1988620 写道

我的处理的原则是，只捕捉checkexception,而忽略RuntimeException。
RuntimeExcepton的产生是程序员的责任，如配置文件写错，空指针引用等。应该是避免这样的异常发生，而不是发生后捕捉处理它。
CheckedException是程序员无法避免的，比如用户的非法输入，非法点击等。这样的异常既然没办法避免，就只能等它发生后再捕捉。

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

18 楼 carlkkx 2011-03-17  

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

17 楼 carlkkx 2011-03-17  

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

16 楼 carlkkx 2011-03-17  

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

15 楼 carlkkx 2011-03-17  

icanfly 写道

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

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

14 楼 carlkkx 2011-03-17  

scvptz 写道

carlkkx 写道

shadowlin 写道

cobb.chan 写道

我的做法是统一 throw new Exception("exception message" + e.getMessage) 直接抛出去

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

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

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

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

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

13 楼 scvptz 2011-03-17  

carlkkx 写道

shadowlin 写道

cobb.chan 写道

我的做法是统一 throw new Exception("exception message" + e.getMessage) 直接抛出去

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

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

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

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

12 楼 icanfly 2011-03-17  

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

11 楼 carlkkx 2011-03-17  

shadowlin 写道

cobb.chan 写道

我的做法是统一 throw new Exception("exception message" + e.getMessage) 直接抛出去

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

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

10 楼 shadowlin 2011-03-17  

cobb.chan 写道

我的做法是统一 throw new Exception("exception message" + e.getMessage) 直接抛出去

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

9 楼 cobb.chan 2011-03-17  

我的做法是统一 throw new Exception("exception message" + e.getMessage) 直接抛出去