抛出异常还是约定返回值

具体场景如下:
现在要执行一个业务操作方法,这个业务方法执行要有N个前置条件满足才能执行
    现在使用统一MVC架构,调用者要收到反馈,知道没ok,并知道是具体哪个前置条件没有ok,再根据对应的规则,反馈进行一些列的后续操作,比如通知用户去哪完善,怎么完善
那么怎么处理?
第一种:N个前置条件的检验,放到action里面做,如果不满足返回相关页面之类的
优点:开发直接简单
缺点:思维直接控制层充斥着这样的业务逻辑,很乱,复用性不强,换个action执行这个,还要再组装

第二种:N个前置条件和业务方法在一块组成一个service方法,直接调用就ok了
作为有追求的coder,我们肯定要第二种,那么第二种问题来了
问题:
这一系列走一流程,写成一个方法完成,那么前置条件到底是第一个不满足,还是第N-1个不满足,怎么得到反馈
解决方式1:抛出不同的异常来完成通知
好处:不满足方法的约定,直接给出异常,
缺点:感觉上犯了异常代替了正常流程的问题,不是很确定
解决方式2:根据返回值来通知相关情况,但这种检测条件满足否
有点:性能方面,约定一些列的final String 或者  Eunm ,也算直观吧
缺点:方法返回值承载了太多东西

大家有什么看法?转头什么的扔吧

action：

    各种值和get set

    public String execute() throws Exception {
        return service.doInService(this);

    }

   
service

    public String doInService(Action action){
        //计算
        //通过action的set设值
        //返回控制路径
    }

简单的方法，不过我并不喜欢

这个耦合也太严重了,快回到解放前了.

我觉得异常的好处是直接返回栈低
只有一层的话，用返回值比较理想吧

个人认为：
根据每个条件返回相应的值。再对可能发生的异常定义相应特殊的值，发生异常时，直接把对应的异常值返回。

所以我也不喜欢啊

仔细分析一下，假设页面表单有变动，action必然变动，
从业务角度来说，就是业务的目标没变，但是细节变化了

从封装变化的角度讲，我们希望变化不要层层蔓延，既然action变化了，service最好可以不变，要降低耦合，可以考虑在action里加一些方法

action：

    各种值和get set

    public String execute() throws Exception {
        return service.doInService(this);

    }

    validator()

    List sqlAndArgs()


   
service

    public String doInService(Action action){
        if(action.validator().valid()){
           for(toQuery:action.sqlAndArgs()){
               dao.query(toQuery);
               ....
           }
           ....
        }else{
           ....
        }
    }

这个很简单啊，如果只是简单统计条件的完成状态：即状态只有（完成1和未完成0）两种
比如条件少于64种，直接用一个long值(64位)来统计（大于64种的用BitSet），约定条件1对应第1个bit，条件2对应第2个bit...条件完成则对应位置1，否则置0
所有条件判断完以后，对这个long值或bitset统计就可以知道条件的完成状态了

你理解错了
Lz想说的是ture和false不能满足
中断操作，第一错误就返回了

感觉还是抛异常吧，是否可以抛出一种异常来，在异常里面封装不同的错误返回值？

？条件没通过就直接返回么？
这个也很简单啊，还是按上面的方法，只是这个long值或bitset是作为上一层传递进来的参数
然后在返回处对long值或bitset判断就可以了啊

这种情况可以结合异常/返回使用，只定义一种异常就足够了，同时返回也没必要被占用来专门做状态返回，异常只是用来做逻辑跳出，并不用来做条件标识