DAOException 在业务层的处理方式

在dao层通常会抛出一个DaoException如下

class UserDao{
    public void insert(User user)throws DAOException{
        //dao code
    }
}

在业务层调用时应该怎样处理这个DAOException呢？
个人认为用两种方式 第一种方式： 不进行处理直接抛给web层  第二种方式 转换成某种业务异常
第一种的缺点是将底层的异常暴露给了客户端  优点是web层可以明确感知到dao层发生异常并告知浏览器用户
第二种正好跟第一种相反： 缺点是web层不知道发生了dao异常，catch到的是一个业务异常，优点是dao异常不会暴露给web层
现在就到底使用那种方式比较困惑

评论

10 楼 银色幻想 2006-11-26  

这样的话dao层是不是不用写log了,直接在service层和web层记录

9 楼 抛出异常的爱 2006-11-24  

xly_971223 写道

抛出异常的爱 写道

在你们看来?
日志这东西是没用的....

如果是非预见异常直抛...
如果是可预见异常处理一下写个日志就行
而且DAO异常与Service异常共用?
.....强

请问 抛出异常的爱 是怎么处理的呢？

好别扭的....发问?

在Serviec层中所有能想到与必作的异常都捕捉

不能想到的用serviceException包装后抛出

8 楼 xly_971223 2006-11-24  

抛出异常的爱 写道

在你们看来?
日志这东西是没用的....

如果是非预见异常直抛...
如果是可预见异常处理一下写个日志就行
而且DAO异常与Service异常共用?
.....强

请问 抛出异常的爱 是怎么处理的呢？

7 楼 抛出异常的爱 2006-11-24  

在你们看来?
日志这东西是没用的....

如果是非预见异常直抛...
如果是可预见异常处理一下写个日志就行
而且DAO异常与Service异常共用?
.....强

6 楼 ddandyy 2006-11-24  

业务判断到插数据库还是有间隔的
理论上说  这个异常一定会出现的

5 楼 xly_971223 2006-11-24  

myreligion 写道

我们的做法是所有异常在web层处理，通过spring的那个exceptionHandler把异常分到不同的页面上，然后给出通用的提示信息，好比没有权限，密码错误，系统错误....。然后在页面的隐藏地方把堆栈信息打出来，方便沟通与调试的时候使用。

我也倾向于myreligion这种方式
现在的问题是 DAOException是直接传到web层还是转换成业务异常

4 楼 xly_971223 2006-11-24  

ddandyy 写道

只扔这个太大了一些吧

如果是主key重复之类的  应该是要报过去的

其他的比如连不上DB之类的   写ERROR_LOG文件就是了

在DAO层是这样处理的 ：将所有的在访问数据中遇到的异常都转换为DAOException，被转换基本上都是一些不可预知的异常 如数据库连接错误  hibernateException等
实际上我个人认为这类异常即使抛出，基本我们也没有办法处理。 所以在有些应用种直接抛出RuntimeException
至于主键重复之类的 我觉得应该放在业务层去判断比较好 而不应该直接去插 等待重复时报告异常

3 楼 myreligion 2006-11-24  

我们的做法是所有异常在web层处理，通过spring的那个exceptionHandler把异常分到不同的页面上，然后给出通用的提示信息，好比没有权限，密码错误，系统错误....。然后在页面的隐藏地方把堆栈信息打出来，方便沟通与调试的时候使用。

2 楼 together 2006-11-24  

就某些应用而言，把详细的error暴露给web层也不见得是坏事。
用户那边可能没有专业的技术人员，你叫他去后台查log可能不太现实。让用户直接看到详细的错误信息，沟通起来也方便一些。当然我们的用户都比较弱的。

最我见过的一个弱智的报错方式，用户登录不成功，系统就报一个“您的用户名或密码不正确，无法登录”。而实际上有多种可能的，可能是数据库没连接上，可能是sql语句本身就是写错了，也可能用户不存在，也可能密码不对，也可能用户被禁用。但是你报这个错误出来给用户，就很难沟通解决问题。

1 楼 ddandyy 2006-11-24  

只扔这个太大了一些吧

如果是主key重复之类的  应该是要报过去的

其他的比如连不上DB之类的   写ERROR_LOG文件就是了