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

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

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

 

DataAccessException extends RuntimeException  Dao层异常

ServiceException extends RuntimeException   Service层异常

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

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

 

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

 

评论

8 楼 qianhd 2011-03-17  

carlkkx 写道

我认为关于Checked exceptions 已经尘埃落定，结论就是：Checked exceptions是失败的设计。C#放弃这个不是没有道理的。

如果eclipse的默认处理 是throws exception 而不是try catch
那对于不懂的开发人员 也就不会随意的压制异常

设计是好的 完全可以通过方法声明看出 这个方法调用是否可能会抛出异常
但是过于学院派 实用型差点

7 楼 kevin1988620 2011-03-17  

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

但是现在jdk设置了太多的checkexception，它们中很多都可以归类于RuntimeException的，导致程序中大量出现大量的try,catch,而catch后又不知道怎么处理，简单的打印一下，其实这样的异常处理没有任何意义，但又不得不如此，比较悲剧。

6 楼 xichao007521 2011-03-17  

我的做法是定义两类异常，DaoException，BizException,然后利用AOP将DAO层和Biz层的异常捕获然后转化为自定的两类异常，然后往上抛。
这样开发人员不过多需要考虑异常了，代码也会整洁很多

5 楼 carlkkx 2011-03-17  

我认为关于Checked exceptions 已经尘埃落定，结论就是：Checked exceptions是失败的设计。C#放弃这个不是没有道理的。

4 楼 carlkkx 2011-03-17  

Checked exceptions 显然已经是失败的设计。
异常的抛出者不应该强迫调用者处理异常，因为你不能决定谁来处理你。这明显是武断的。
而且这种强迫还导致很多人乱吞异常，就像qianhd所描述的那样。

事实我们只有需要一种方便的描述我可能抛出的异常，但不是编译级别的强迫。

3 楼 qianhd 2011-03-17  

异常要抛给有能力处理这个异常的handler
但是这个道理很多人不懂 所以经常会压制异常
随便try catch一下 然后连打印都不打印
与其让不懂的人搞乱异常机制
还不如用runtimeException 然后再需要的地方 或者有能力处理的地方统一的catch一下

2 楼 IcyFenix 2011-03-16  

checked exception有没有必要确实是一个很老的话题了，曾经巨牛级的人物在上面发生过很大的争论。在小规模的程序中，确实能用得很优雅，但是大规模程序往往就会沦为鸡肋。

在spring的Mission Statement中，就有这样一句：

Checked exceptions are overused in Java. A platform shouldn't force you to catch exceptions you're unlikely to be able to recover from.

1 楼 sandssss 2011-03-16  

对于自己的Util这样的方法，我自己一般是都是把异常catch到，然后return一个默认的空值（null,或者0这样的）