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代码在异常处理方面的方案和出现的问题，如何更好地解决异常处理问题，提供我们程序的健壮性我们值得进一步思考，待续。。。。
最新文章
- MySql: log 位置
- [转]struts1.2的action参数配置
- ionic tabs置顶
- Symmetric Difference
- 也说说angularJs里的evalAsync
- 软件工程（C编码实践篇）课程总结
- jQuery waterbubble 水球图
- Nexus4_屏幕截图目录
- 笔记本_hp
- bzoj2668
- dumpbin.exe
- 9.21 investments - chapter 4 - Summary
- android下文件下载
- samba的安装和配置
- thinkphp系列：类的自动加载是如何设计的
- Unity手游之路手游代码更新策略探讨
- Sql_join left right
- python笔记之强制函数以关键字参数传参
- 【NOI】2017 整数（BZOJ 4942，LOJ2302） 压位+线段树
- textAlign
热门文章
- 拒绝了对对象 'base_config' (数据库 '****'，架构 'dbo')的 SELECT 权限
- java 遍历arrayList的四种方法
- 《深入理解Java虚拟机》垃圾收集器
- Hadoop学习笔记—21.Hadoop2的改进内容简介
- C++的性能C#的产能?! - .Net Native 系列《二》：.NET Native开发流程详解
- [nRF51822] 8、基础实验代码解析大全 · 实验11 - PPI
- 如何使用Worktile进行敏捷项目开发管理
- RabbitMQ Exchange & Queue Design Trade-off
- PHP设计模式笔记
- CATransition转场动画