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

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

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

 

DataAccessException extends RuntimeException  Dao层异常

ServiceException extends RuntimeException   Service层异常

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

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

 

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

 

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

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.

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

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

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

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

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

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

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

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

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

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