js构建ui的统一异常处理方案(一)

从早期从事基于java的服务器端开发,再到之后从事基于web和js的ui开发,总体感觉基于web页面的ui开发远不如服务器端健壮。主要是早期ie浏览器功能太弱小,很多业务被迫放到服务器端去实现,浏览器端技术设计的比较简单。其次,js这门语言对于异常里也不够完善,没有一套足够完善的异常处理思路,尽管js存在throw、try、catch这种异常的语法,但是js本身是一门函数式编程的语言,try、catch在很多回调场景中是那么无力。

所以一直以来我就想构建出一个完善的js异常处理机制,而且还要基于具体ui实际需求,做出具体的处理逻辑。简单来说,当boss问我们做这种统一的异常处理有什么好处时,作为前端工程师,最理想的回答就是增加用户体验,作为前段工程师,用户体验是我们最大的价值,因为只有增加用户体验,公司才能留住用户,保持盈利,我们才能发挥出价值。那么如何提升用户体验呢?当用户遇到了不同的错误情况,使用最适合的提示方式提供给用户,不就是增加了用户的使用体验吗?

所以统一的异常处理的目的就是,能够使用简单、严谨的思路让程序员开发出更容易维护的代码,增加前端js代码的健壮性,同时将异常处理的提示具体实现和业务逻辑解耦,由统一的提示接口去将处理异常信息。

那么这我们提出设计方案之前,先来分析一下传统的异常处理方法,以及js中使用时候的问题,也来想想为什么我们平时在js中使用异常处理的情况是那么少。

1.责任链模式的异常处理理论

传统的异常处理理论,就是一个责任链模式,当方法A调用方法B,方法B调用方法C,其中每一个方法其实都可能抛出异常,可能处理异常。

function f(){
    try{
    } catch(e){
        //什么也不做
        throw e;      
    }                
}

//等效于
function f(){}

本身方法调用就是一个链,而异常处理则处于这个链上。当一个方法抛出一个异常时,他本也是异常的第一个接收人(catch到异常),如果是他职责身份能处理的异常,他就应该立刻处理此异常,不再向上抛出;否则就应该向上抛出,抛到上一层方法。依次类推,直到抛到最顶层。通常这个最顶层是一个用户或者系统调用接口,这个接口作为方法调用的发起者,同时也应该是异常处理的最终响应者,在这一层我们将真正地去处理底层方法无法处理的异常。

如何判断一个异常是一个方法能否处理的呢?依据“最小知道原则”和“职责单一原则”,一个异常如果属于其业务范围内的一部分,就应该处理这个异常,如果需要外界知晓这个异常存在,就应该将这个异常加工后抛到上一层。

function fa(){
    try{
        fb();
    }catch(e){
        if(e == "方法a能处理的异常"){
            console.log("方法a处理了异常")
        } else {
            console.log("方法a无法处理此异常,继续向上抛出")
            throw e;
        }
    }
}
function fb(){
    try{
        fc();
    }catch(e){
        if(e == "方法b能处理的异常"){
            console.log("方法b处理了异常")
        } else {
            console.log("方法b无法处理此异常,继续向上抛出")
            throw e;
        }
    }
}
function fc(){
    try{
        throw "方法acb都不能处理此异常";
        //throw "方法a能处理的异常";
        //throw "方法b能处理的异常";
        //throw "方法c能处理的异常";
    }catch(e){
        if(e == "方法c能处理的异常"){
            console.log("方法c处理了异常")
        } else {
            console.log("方法c无法处理此异常,继续向上抛出")
            throw e;
        }
    }
} 

(function(){
    try{
        fa()
    }catch(e){
        console.log("最顶层处理了此异常");
    }
})()

其中a、b、c中如果没有可以处理的异常,try、catch语句是可以省略掉的,这样代码就会简写为

function fa(){
    fb();
}
function fb(){
    fc();
}
function fc(){
    throw "方法acb都不能处理此异常";
} 

(function(){
    try{
        fa()
    }catch(e){
        console.log("最顶层处理了此异常");
    }
})()

是不是简单了不少,我们实际开发中更多的是这种例子,因为一个函数出现错误,后续执行都将无法正常进行,所以是需要向上层抛出的。因此js语法中的异常处理策略简化了整个过程。

所以说,传统的异常处理就是一个责任链模式。然而js中真的就可以使用这种责任链模式的异常处理吗?为什么我们在开发js中,很少采用这种责任链模式的异常处理呢?接下来我们继续介绍js的异步调用。

2.js异步调用的异常处理

js是个很神奇的语言,用这个语言你可以像用c语言那样在全局变量里,面向过程地编写你的代码,也可以像使用java那种,面向对象地编写代码,他还可以使用现状渐渐开始火起来在函数式的方法编写代码。

在js里面,函数可以向变量一样被声明,可以做方法的入参,可以做方法的返回值,这些都是js不可或缺的语法特性。

因为js还有没有语法级的阻塞方案,这样你无法同步两个不同的线程能够同步彼此,例如一个异步请求,或者调用。当调用一个异步方法,因为没有语法级的阻塞方式,所以整个调用过程中,你无法顺序地编写调用过程,唯一能做的事情只有回调。

这些语法特性使得我们开发的时候,只能做到基于函数回调情况去处理不同的状况,而责任链模式的异常处理也变得不再适用。

function f(){
    throw "error";  
}

try{
    setTimeout(f)
} catch(e){
    console.log(e)  //接收不到这个error的
}

这种情况在实际开发中会经常遇到。最常见的就是一个ajax的异步请求,除此之外,异步io的api、地理定位的api、摄像机的api,这些都是异步的。再比如我们模拟一个alert方法,不使用系统的alert而是我们自己的alert(系统的alert函数调用后会弹出真正的模式对话框,此时线程挂起,运行阻塞,当用户点掉alert对话框后线程才会唤起)。与系统alert不一样,我们自己做的alert只能在回调里加alert后续的业务方法。

//使用Window对象的alert
alert("我被阻塞了");
console.log("执行完毕");

var myAlert = {
    show: function(fn) {
        //绘制alert对话框略

        //监听用户点击事件,点击后回调fn函数
        var body = document.querySelector("body");
        var _fn = function() {
//去除对话框略 body.removeEventListener(
"click", _fn) fn && fn(); } body.addEventListener("click", _fn, false); } } //调用自定义的alert myAlert.show(function() { console.log("执行完毕"); })

这种回调在js程序设计中常常被用到,因为这种方式是不支持责任链模式的,所以try、catch这种异常处理的语法在这种调用中很少会被使用到。那么这种基于回调的调用过程,一般使用什么方法做异常处理呢?通常函数本身会有一个错误的回调入参,参数要求是一个我们还是使用a、b、c这三个方法彼此调用来说明。

function fa(error){
    var errorFn = function(e){
        if(e == "方法a能处理的异常"){
            console.log("方法a处理了异常")
        } else {
            console.log("方法a无法处理此异常,继续向上抛出")
            error && error(e);
        }
    }
    
    setTimeout(function(){
        fb(errorFn);
    })
}    
function fb(error){
    var errorFn = function(e){
        if(e == "方法b能处理的异常"){
            console.log("方法b处理了异常")
        } else {
            console.log("方法b无法处理此异常,继续向上抛出")
            error && error(e);
        }
    }
    
    setTimeout(function(){
        fc(errorFn);
    })
}    
function fc(error){
    var errorFn = function(e){
        if(e == "方法c能处理的异常"){
            console.log("方法c处理了异常")
        } else {
            console.log("方法c无法处理此异常,继续向上抛出")
            error && error(e);
        }
    }
    
    setTimeout(function(){
        try{
            throw "方法acb都不能处理此异常";
            //throw "方法a能处理的异常";
            //throw "方法b能处理的异常";
            //throw "方法c能处理的异常";
        }catch(e){
            errorFn(e);
        }
    })
}

fa(function(){
  console.log("最顶层处理了此异常");
})

注意这里的errorFn是不可以省略的,因为这个责任链模式是我们手动书写出来的。所以要想实现异步过程的责任链模式,是必须通过自己手动完成的,js并没有提供什么语法糖帮我们简化这个过程(其实也是有的)。

而且,只有最里层的fc当中使用try、catch语句,fb、fa都无法再使用try、catch语句了,因为一旦使用了这种回调方案,就再也无法回归传统的try、catch处理了,这也是try、catch语法无法在js里面流行的一大原因。

这里基本分析出了传统js代码在异常处理方面的方案和出现的问题,如何更好地解决异常处理问题,提供我们程序的健壮性我们值得进一步思考,待续。。。。

posted @ 2016-03-19 10:01  laden666666  阅读(...)  评论(...编辑  收藏