请问业务层方法是抛出一个异常好还是返回一个结果更好
博彩导航网站排行榜
博彩导航网站排行榜
当前位置 : 博彩导航网站排行榜 > 博彩导航网站排行榜

请问业务层方法是抛出一个异常好还是返回一个结果更好

@Override
    public Response<LoginDTO> checkUserTokenlong uid, String accessToken, String deviceToken{
        Response<LoginDTO> response = new Response;
        //TODO 先到session中找
        try {
            UserLogin userLogin = userLoginDao.getUserLoginByUiduid;
            ifuserLogin != null {
                ifuserLogin.getStatus !=-1{
                    ifaccessToken == userLogin.getAccessToken && deviceToken == userLogin.getDeviceToken{
                        //验证正确, 生成新的accessToken
                        String newAccessToken = regenerateAccessTokenuid;
                        //保存到数据库
                        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.executeUpdatesql, args, argTypes;

                        response.setRcRc.RC_SUCCESS;
                        response.setDatanew LoginDTOuid, accessToken, deviceToken;
                    }else{
                        response.setRcRc.RC_USER_ACCESS_ERROR;
                        response.setErrMsg"验证失败,请重新登陆";
                    }
                }else{
                    response.setRcRc.RC_USER_STATUS;
                    response.setErrMsg"账号存在风险,已暂时锁定";
                }
            }else{
                response.setRcRc.RC_USER_INVALID;
                response.setErrMsg"不合法用户请求";
            }
        }catch Exception e{
            Yin.logErrore, getClass;
            response.setRcRc.RC_DB_ERROR;
            response.setErrMsg"数据库异常";
        }
        return response;
    }
  1. 这是一个业务层方法, 里面我直接try catch捕获了dao层的可能的异常. 并作为一个对象返回.
    我的考虑是:这么做的在action层就无需try, catch了,因为统一通过Response返回结果

  2. 我看有的人是封装了一个业务层的异常, 返回给action
    这两种方法哪个好些?为什么?

  3. 另外, 如果是封装业务层的异常,这个按照什么原则分的呢? 比如 前台传个id, 如果这个id没找到,难道我要构造个UserNotFoundException, 而不是在Response对象里加一个status?

小弟学程序至今, 一直觉得自己写的代码很糟糕, 最近开始看代码大全这本书, 觉得受益匪浅, 并重新修改了代码.麻烦各位前辈解惑的同时, 能指点一下如上这段代码. 请指教

我的设计一般是DAO层不处理任何异常,Service层调用DAO层并捕获异常,然后通过一个状态码将信息返回给Action层。
个人觉得,Action层的逻辑尽量简单些为好,因为Action是接口层,太复杂让人难以一眼看穿接口要提供的功能。

错误码在面向过程的语言中非常常见,但是在面向对象的过程中,使用异常来处理多一点。
使用错误码的缺点是:
1、对错误的检测不是强制的
2、代码充斥各种if else的错误码判断
使用异常的好处是:
1、对错误的检测是强制的,你必须处理或者上抛异常
2、代码不必对各种状态码进行判断,有异常直接抛出终止往下运行
3、对于错误有堆栈可以追踪。

库抛异常,业务返回错误码。

我觉得这主要看两点:1各层的逻辑量的轻重,则需要你自己取舍;2个人风格,我比较喜欢能在业务层处理的尽量处理,但dao层只抛异常。其实哪里处理都行,只要不直接返回给客户端就好。

业务层都是if else 基本都是调用数据 返回前应该设置默认值比如空值 只有dao类可能与业务层之外的系统交互,数据库,网络 出现异常的概率更大,所以应该在dao类里面妥善处理异常 业务层/ action返回空值/缺省值 这样对用户更友好

持久化这块一般不进行逻辑处理,往上一级抛最好,不然以后要改用一些持久化框架了移植起来太麻烦
虽然造成异常的情况有很多,但对用户的结果来说就是没成功,至于为什么没成功是留给开发人员看的,所以我认为不用返回这么多种结果,直接返回异常开发人员通过查看哪种异常也能判断原因
我想你要记录这个应该是用来判断如果出错了是哪里出错是吧,打印日志应该是一个挺普遍的做法,把异常之类的加入到日志里

嵌套了多少层?
先学会减少嵌套吧

另外service层就是返回确定的结果,它就是处理异常和业务逻辑的
action层起到路由的作用,调用该调的service直接返回就好

我在知乎问过这个问题:https://www.zhihu.com/question/36278363
敬请参阅。

你这个例子无所谓,
但是存在事物的情况下,就有所谓了,
如果你使用的是申明式事物,那么事务中的某一个中间环节出错,因为错误直接抛出,所以可以在事务开启的那一层被catch到,并回滚当前事务中所有的操作,
如果你在dao曾捕获了异常,那么感知这个业务是否需要回滚就变得很麻烦,需要对每一个dao操作结果进行判断。

最新文章

广告位

博彩导航网站排行榜