@Override
public Response<LoginDTO> checkUserToken(long uid, String accessToken, String deviceToken){
Response<LoginDTO> response = new Response();
//TODO 先到session中找
try {
UserLogin userLogin = userLoginDao.getUserLoginByUid(uid);
if(userLogin != null) {
if(userLogin.getStatus() !=-1){
if(accessToken == userLogin.getAccessToken() && deviceToken == userLogin.getDeviceToken()){
//验证正确, 生成新的accessToken
String newAccessToken = regenerateAccessToken(uid);
//保存到数据库
String sql = "UPDATE " + UserLoginDao.DEFAULT_TABLE_NAME + " SET " +
"accessToken=?, online=?";
Object[] args = new Object[]{newAccessToken, 1};
int[] argTypes = new int[]{Types.VARCHAR, Types.TINYINT};
userLoginDao.executeUpdate(sql, args, argTypes);
response.setRc(Rc.RC_SUCCESS);
response.setData(new LoginDTO(uid, accessToken, deviceToken));
}else{
response.setRc(Rc.RC_USER_ACCESS_ERROR);
response.setErrMsg("验证失败,请重新登陆");
}
}else{
response.setRc(Rc.RC_USER_STATUS);
response.setErrMsg("账号存在风险,已暂时锁定");
}
}else{
response.setRc(Rc.RC_USER_INVALID);
response.setErrMsg("不合法用户请求");
}
}catch (Exception e){
Yin.logError(e, getClass());
response.setRc(Rc.RC_DB_ERROR);
response.setErrMsg("数据库异常");
}
return response;
}
这是一个业务层方法, 里面我直接try catch捕获了dao层的可能的异常. 并作为一个对象返回.
我的考虑是:这么做的在action层就无需try, catch了,因为统一通过Response返回结果我看有的人是封装了一个业务层的异常, 返回给action这两种方法哪个好些?为什么?另外, 如果是封装业务层的异常,这个按照什么原则分的呢? 比如 前台传个id, 如果这个id没找到,难道我要构造个UserNotFoundException, 而不是在Response对象里加一个status?
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
错误码在面向过程的语言中非常常见,但是在面向对象的过程中,使用异常来处理多一点。
使用错误码的缺点是:
1、对错误的检测不是强制的
2、代码充斥各种if else的错误码判断
使用异常的好处是:
1、对错误的检测是强制的,你必须处理或者上抛异常
2、代码不必对各种状态码进行判断,有异常直接抛出终止往下运行
3、对于错误有堆栈可以追踪。