讲讲我们使用异常的经验

讲讲我们使用异常的经验

在我们现在的系统中，有一个这样的需求：有一个抽奖活动，用户参加可以随机获得奖品。但是用户能否参加活动有一系列的业务规则。例如活动本身处于打开（open）的状态；当前时间在活动的开始时间结束时间内；一个ip只能参加20次活动；用户要登录过游戏。。。等等等等。当用户参加了活动，出现异常的时候，我们还要告诉他异常的原因。

在以前，处理这种问题的时候，我们使用错误码来解决。我们这么设计参加活动的函数

public int join（User user){//某位用户参加了活动。0、表示成功 1、活动已关闭 2、活动未开始或已结束
……
}

这样的话，客户代码就会显得很麻烦，他要写很多if来告诉客户端错误原因

int ret = server.join(user);
if(ret==1)
        msg = "活动已关闭";
else if(ret==2)
        msg="活动未开始或已结束";
else if(ret==3)
        ......

这样的代码也会冗余，只要有几个地方调join函数，就要把这个if列表重新写一遍。如果有新的规则加进来，比如说，要增加一个规则，我们的活动只有充值过的用户才能参加，用错误码6表示这个错误。那么所有调用的地方必须加一个 if(ret==6)。

可以看出来，这种写法的扩展性很差。我们的解决方案是用自定义异常来解决。不返回任何错误码，当用户不能参加活动时候，抛出一个runtimeexception的子类来告诉客户端有异常产生。

参加活动的函数被设计成
public void join（User user){
……
}

客户代码就很简洁
try{
        server.join(user);
}catch(Exception e){
        msg = e.getMessage();
}

再观察一下，我们可以发现 try……catch……，也可以统一处理，我们可以把他放到struts2的拦截器里面。我们写了一个统一的异常处理拦截器。
public class ErrorInterceptor extends AbstractInterceptor{
        public String intercept(ActionInvocation invocation) throws Exception {
                String ret = null;
                try{
                        ret = invocation.invoke();
                }catch(Exception ite){
                        //将异常信息放到客户端，并将页面跳到错误页面
                        ServletActionContext.getRequest().setAttribute("error", "true");
                        ServletActionContext.getRequest().setAttribute("msg",ite.getMessage());
                        ServletActionContext.getRequest().setAttribute("errorCode",ite.getClass().getSimpleName());
                        ret = "error";
                        ite.printStackTrace();
                }
                return ret;
        }
       
}

这样，调用活动的客户代码就变得异常简单。只有一句
server.join(user);

如果使用ajax，我们也可以为异常写一个通用的异常js处理类。
activeServer.join(
        new ErrorProcesser('active_error') //将异常信息显示在domid为active_error的div中，同时修改css
)

如果要对某个异常特殊处理，也很容易扩展。比如如果活动没打开，我需要alert出来，而不是像其他异常一样显示在div中。ErrorProcesser的代码可以这么写

process:function(error){
        if(error.errorCode=='NoOpenExp')
                alert("亲，活动没打开");
        else
                $("#"+this.domId).html(errorCode.errorMsg);

}

如果想在服务端对异常做特殊处理，也很容易扩展。你可以实现一个自己的异常父类MyExp，其他想要特殊处理的异常继承这个异常。拦截器的代码就变成
try{
        ret = invocation.invoke();
}catch(MyExp myExp){
        myExp.process();
}catch(Exception ite){
        ……
}
return ret;

上述异常设计思路是：异常，是可以统一处理的。我们的执行代码只要抛异常，调用代码只要调用程序处理正确流程就可以了，异常拦截器帮你统一处理了错误流程。

这样执行代码也很容易扩展，比如我们又加一个需求，我还要告诉用户参加活动得了什么奖品。用错误码就比较困难扩展，因为他返回的int。而用异常处理就比较容易，把接口改成
Prize join（User user);

客户的调用代码改成
Prize prize = server.join(user);
this.prizeName = prize.getName();

还有一种扩展的需求，就是我写join方法的时候也不知道错误规则是什么。因为每个活动都有各自的规则，我也不知道以后哪些活动有哪些规则。那么这样我们就要抽象出一个IRuleChecker接口，他仅有一个方法
void check(User user);

每个活动都有一个list装了很多接口的实例，每次执行join的时候首先都会轮询list调用每个IRuleChecker的check方法。正确就通过，错误则抛出异常。这样活动可以不知道自己有哪些规则，客户调用代码可以不知道活动会带来哪些异常。他还是只要执行以下两句代码就可以了，反正有专门的异常处理拦截器处理。

Prize prize = server.join(user);
this.prizeName = prize.getName();

从上述例子，我们可以看出使用好自定义异常，会给我们的程序带来很好的可扩展性。但是有人可能会提出性能问题。为此我写了两段代码测试，这两段代码都循环了一百万次。
//用异常
public class ExpTest1 {
        public static void main(String[] args) {
                long time = System.currentTimeMillis();
                ExpTest1 test = new ExpTest1();
                for(int i=0;i<1000000;i++){
                        try{
                                test.test();
                        }catch(Exception e){
                                //System.out.println(e.getMessage());
                        }
                }
                System.out.println(System.currentTimeMillis()-time);
        }

        public void test(){
               
                throw new RuntimeException("出错了");
        }
}
//不用异常，用错误码
public class ExpTest {
        public static void main(String[] args) {
                long time = System.currentTimeMillis();
                ExpTest test = new ExpTest();
                for(int i=0;i<1000000;i++){
                        int ret = test.test();
                        if(ret==1){
                        //        System.out.println("出错了");
                        }
                }
                System.out.println(System.currentTimeMillis()-time);
        }

        public int test(){
                return 1;
        }

}
从时间看，第一段代码花了2秒中，第二段代码花了3毫秒。相差了一千倍。这个数据好像能吓人一跳，但是仔细想想。如果有一天，你的程序抛出一百万个异常给客户端（换句话说用户有一百万次错误的点击），你的系统多花了两秒来处理。平均每个异常大概耗费0.002毫秒。这个我觉得是可以接受，因为在这个0.002毫秒，系统的其他线程正在忙着查数据库，处理http链接等等其他事情。

exception exception

就纯粹的抛出异常，不用状态码，似乎也不大好吧，要是异常消息要国际化呢。

看sina weibo这些的api,基本上的接口调用都是用状态码的，关键是规则。

因为sina weibo这些是《api》，所以不存在所谓的异常啊。。。
况且他们是http上的。

先易读，可扩展，支持

建议不要用异常机制来处理业务逻辑。
处理状态码和消息文本的关联，方式很多，比如enum，properties，map，自己写一个类封装也行。

一个properties文件  一个加载好的 map   抛异常时 传个错误码  统一捕获异常
map取值 丢给前台 就这么简单个东西