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

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

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

 

DataAccessException extends RuntimeException  Dao层异常

ServiceException extends RuntimeException   Service层异常

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

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

 

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

 

评论

48 楼 carlkkx 2011-03-18  

ppgunjack 写道

当a库依赖b库，你调用a库，如果b库全是RuntimeException，并且你拿不到b库文档，你用a库能写出健壮的代码是不可能的，你自己精心构建的异常处理逻辑能轻松被无法预见的RuntimeException打断，因为你预计不到a库什么时候会被b库的雷给牵连，任何对a的调用都要考虑可能由b导致的连环雷
把代码比作做事，RuntimeException就相当于天灾人祸，意外之外的，至于发生了你愿意自己继续干还是终止取决于你自己意愿
而checked就是说你需要弄清楚并且汇报给上级那些是问题，那些是你会遇到但你解决不了的，但都是你意识到的问题，别人让你做事，你要给别人说好，如果让我干可能出现意外1，2，3，怎么处理你自己决定

调用链是a->b->c->d，如果d是没任何这种提前约定的契约，那么a要操心的就是调用b的所有接口，b随时也有可能被c的调用打断，而c随时会被d打断，看似编码简单，实际异常处理被大幅扩大

最简单的例子，你老板让你干活都需要先分析风险，你可能会让底下再分析，然后汇报，然后才是每层自己根据汇报的风险制定计划和执行

如果全unchecked相当于你没任何汇报，只是告诉上级，你让我干事有风险，干什么事都有风险也可能都没风险，你分配我任务的时候自己看着办，还有我下属的风险我可能也转给你也可能不给你我自己搞定，这看我自己风格，你也自己看着办吧

你只跟a有关系，如果a的描述中没有那是a的问题，照你这么说你做每一件事都是寻根问底，否则就不存在安全性了，那封装就没有意义了，因为每一层API你都要看到底，否则你心中没有底。

47 楼 ppgunjack 2011-03-18  

当a库依赖b库，你调用a库，如果b库全是RuntimeException，并且你拿不到b库文档，你用a库能写出健壮的代码是不可能的，你自己精心构建的异常处理逻辑能轻松被无法预见的RuntimeException打断，因为你预计不到a库什么时候会被b库的雷给牵连，任何对a的调用都要考虑可能由b导致的连环雷
把代码比作做事，RuntimeException就相当于天灾人祸，意外之外的，至于发生了你愿意自己继续干还是终止取决于你自己意愿
而checked就是说你需要弄清楚并且汇报给上级那些是问题，那些是你会遇到但你解决不了的，但都是你意识到的问题，别人让你做事，你要给别人说好，如果让我干可能出现意外1，2，3，怎么处理你自己决定

调用链是a->b->c->d，如果d是没任何这种提前约定的契约，那么a要操心的就是调用b的所有接口，b随时也有可能被c的调用打断，而c随时会被d打断，看似编码简单，实际异常处理被大幅扩大

最简单的例子，你老板让你干活都需要先分析风险，你可能会让底下再分析，然后汇报，然后才是每层自己根据汇报的风险制定计划和执行

如果全unchecked相当于你没任何汇报，只是告诉上级，你让我干事有风险，干什么事都有风险也可能都没风险，你分配我任务的时候自己看着办，还有我下属的风险我可能也转给你也可能不给你我自己搞定，这看我自己风格，你也自己看着办吧

46 楼 carlkkx 2011-03-18  

chenkan2000 写道

RuntimeException的意思是：当程序遇到这种异常时是不可恢复的，程序应该终止了，所以捕获这种异常没有意义。一般是最外层程序捕获它，记录日志，发送邮件。

谁这么定义RuntimeException的意思的？完全是胡说，最顶层捕获到未处理异常才应该终止了（当然这也不是一定的）。

这里核心点是未处理异常而不是什么RuntimeException，RuntimeException完全有可能被捕获以及被处理。

45 楼 chenkan2000 2011-03-18  

RuntimeException的意思是：当程序遇到这种异常时是不可恢复的，程序应该终止了，所以捕获这种异常没有意义。一般是最外层程序捕获它，记录日志，发送邮件。

44 楼 accphc 2011-03-18  

spiritfrog 写道

干脆就将异常全设计成unchecked的好了。分两类，需要关注的就叫做ServiceException， 对ServiceException进行业务编号， 代码中捕获ServiceException，根据编号进行业务处理；另外一类，就都当成是系统出错了，交给统一异常处理层了。

这个接近我现在做系统的异常处理方案。只不过我这里dao层封装了DataAccessException，然后统一捕获报告数据库错误。

43 楼 carlkkx 2011-03-18  

这种强暴导致了最后调用者本根不鸟他，直接吞了了事。

42 楼 carlkkx 2011-03-18  

checked excetpion， 对于确实需要处理的异常， 可以明确在编译期间就告诉方法调用者，并且强制让其能做合适的处理，这种情况还是有用的。
——————————————————————————
确实不确实这件事是调用者确定的而不是你这边确定的，如果你认同这个理念那么checked excetpion就是个错误的设计。它赋予了抛出异常方滥用权力，最终导致强暴很多调用者。

41 楼 spiritfrog 2011-03-18  

checked excetpion， 对于确实需要处理的异常， 可以明确在编译期间就告诉方法调用者，并且强制让其能做合适的处理，这种情况还是有用的。但是如果异常没法处理，也采用
checked excetpion，就会导致异常没正确处理或者层层往外throws，这时又显得没必要，而且让代码显得很难看。反之这种情况采用unchecked就比较合适。
checked excetpion，大部分人都会catch，然后简单打印，异常就被吞了；unchecked，因为不会显式throws，也不会强制要求处理，眼不见为净，代码清静许多，只需要做一个统一异常处理层面，对unchecked来个统一性的处理，其实也只要告之操作者系统出错了。
看起来是checked和unchecked是都有各自的优缺点，有适合各自的应用场景，结合它们的优点来用也应该是可以的。但如果非要做取舍，个人的倾向，干脆就将异常全设计成unchecked的好了。分两类，需要关注的就叫做ServiceException， 对ServiceException进行业务编号， 代码中捕获ServiceException，根据编号进行业务处理；另外一类，就都当成是系统出错了，交给统一异常处理层了。

40 楼 peak 2011-03-18  

我设计是整个平台只抛一个异常，DAO自动抛runtime的异常，到service统一捕获，到web统一处理一个异常。。。

39 楼 piao_bo_yi 2011-03-18  

carlkkx 写道

checkexception说白了，他鼓励抛出异常方强暴调用者，会培养武断自大的设计行为。

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

38 楼 accphc 2011-03-18  

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

37 楼 aws 2011-03-18  

需要处理的捕获后处理

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

36 楼 kevin1988620 2011-03-18  

fangin 写道

kevin1988620 写道

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

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

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

35 楼 carlkkx 2011-03-17  

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

34 楼 carlkkx 2011-03-17  

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

33 楼 carlkkx 2011-03-17  

gtssgtss 写道

carlkkx 写道

Jazag.van 写道

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

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

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

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

32 楼 carlkkx 2011-03-17  

ricoyu 写道

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

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

31 楼 gtssgtss 2011-03-17  

carlkkx 写道

Jazag.van 写道

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

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

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

30 楼 ricoyu 2011-03-17  

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

29 楼 carlkkx 2011-03-17  

checkexception说白了，他鼓励抛出异常方强暴调用者，会培养武断自大的设计行为。