业务层捕捉DataAccessException异常并处理

[william61]

一个友好的应用应该提供给用户明确的信息提示，比如说“用户名已经存在” “用户名过长”.....
这些信息根源于数据库中设计的各种约束。当操作出发这些约束的时候，会得到一个spring包装起来的dataAccessException异常。

我现在的做法是在dao包用了一个pointcut,织入了after-throwing通知，打算重新抛一个自定义的异常给业务层。
但是现在的问题是，不知道怎么去细分dataAccessException，只能用ex.getRootCause()得到一些信息。

[believefym]

其实像用户名过长等，可以在前期就处理掉，而不用到DAO层
这些检查是有必要的，可以防止注入式攻击，包括有效字符，长度等

像楼主的需求，可以分析一下rootcause，抽象出某几个业务层的信息就可以了，其他的可以可以归为一类

[zl3450341]

这样的在客户端判断就好了
js验证

[道光2008]

在jsp页面用ajax请求校验，这样可以减少没有必要的提交次数

[howsun_zh]

楼主的解决方案好像并不能通过Exception对象来抛“用户名已经存在” “用户名过长”.....这些信息，除非手动地在aop中判断字符串大小，并throw一个Exception对象，这样是不是觉得有点死板？因为aop横向切面方式面积整个系统，而不是针对某个字段。

如果抛开楼上几位在web层解决方案的话，我觉得在逻辑层有两种方案尚佳：
1、用Hibernate验证，例如：

@Length(max=30,message="用户名最多只能为30个字符")
private String username;

然后可用以下这个方法来检测实体：
ClassValidator<T> cv = new ClassValidator(clazz);
InvalidValue[] message = cv.getInvalidValues(t);
if(message.length > 0){
for(InvalidValue iv : message){
//iv.getPropertyPath()为出错的属性
//iv.getMessage());为该属性出错的消息
}
}
}
通过Hibernate事件也可以检测JDBC反馈消息，例如不能插入重复值。

2、用楼主所说的AOP方案
但最好也参考Hibernate的验证思想，即在实体上用注解的方式(或xml)来标定每个属性的长度、唯一性、数据库类型等等。

@valid(length={30,"长度不能超过30"},unique={true,"用户名必须唯一"})
private String username;

然后在aop的point中拦截要被保存或更新的实体，用内省和反射来检测每个属性配置的长度并抛错，其实是和Hibernate验证是一个道理，无非这样好控制一些，例如可以控制到数据进入数据库时发生的错误——用户名重复等等