本文转载自网络。转载编辑过程中,可能有遗漏或错误,请以原文为准。

原文作者:肥仔John

原文链接:https://www.cnblogs.com/fsjohnhuang/p/7685144.html

编程时我们往往拿到的是业务流程正确的业务说明文档或规范,但实际开发中却布满荆棘和例外情况,而这些例外中包含业务用例的例外,也包含技术上的例外。对于业务用例的例外我们别无它法,必须要求实施人员与用户共同提供合理的解决方案;而技术上的例外,则必须由我们码农们手刃之,而这也是我想记录的内容。
我打算分成《前端魔法堂——异常不仅仅是try/catch》和《前端魔法堂——调用栈,异常实例中的宝藏》两篇分别叙述内置/自定义异常类,捕获运行时异常/语法异常/网络请求异常/PromiseRejection事件,什么是调用栈和如何获取调用栈的相关信息。
是不是未出发就已经很期待呢?好吧,大家捉紧扶手,老司机要开车了^_^

一.异常还是错误?它会如何影响我们的代码?

在学习Java时我们会被告知异常(Exception)和错误(Error)是不一样的,异常是不会导致进程终止从而可以被修复(try/catch),但错误将会导致进程终止因此不能被修复。当对于JavaScript而言,我们要面对的仅仅有异常(虽然异常类名为Error或含Error字样),异常的出现不会导致JavaScript引擎崩溃,最多就是让当前执行的任务终止而已。
上面说到异常的出现最多就是让当前执行的任务终止,到底是什么意思呢?这里就涉及到Event Loop的原理了,下面我尝试用代码大致说明吧。

<script>
  // 1.当前代码块将作为一个任务压入任务队列中,JavaScript线程会不断地从任务队列中提取任务执行;
  // 2.当任务执行过程中报异常,且异常没有捕获处理,则会一路沿着调用栈从顶到底抛出,最终终止当前任务的执行;
  // 3.JavaScript线程会继续从任务队列中提取下一个任务继续执行。
  function a(){throw Error("test")}
  function b(){a()}
  b()
  console.log("永远不会执行!")
</script>
<script>
  // 下一个任务
  console.log("你有你抛异常,我照样执行!")
</script>

二.内置异常类型有哪些?

说到内置异常类那么必先提到的就是Error这个祖先类型了,其他所有的内置异常类和自定义类都必须继承它。而它的标准属性和方法就以下这寥寥几个而已

/**
 * @prop {String} name - 异常名称
 * @prop {String} message - 供人类阅读的异常信息
 * @prop {Function} constructor - 类型构造器
 * @method toString():String - 输出异常信息
 */ 

另外巨硬还新增以下两个属性

/**
 * @prop {String} description - 和message差不多
 * @prop {number} number - 异常类型的编号,巨硬为每个异常设置了一个唯一的编号
 */

那么现在我要实例化一个Error对象,只需调用Error()new Error()即可;若想同时设置message,则改为Error("test")或new Error("test")。其实Error的构造函数签名是这样的

/**
 * @constructor
 * @param {String=} message - 设置message属性
 * @param {String=} fileName - 设置fileName属性
 * @param {number=} lineNumber - 设置lineNUmber属性
 */

现在我们看看具体有哪些内置的异常类型吧!

  • EvalError,调用eval()时发生的异常,已被废弃只用于向后兼容而已
  • InternalError,JavaScript引擎内部异常,FireFox独门提供的!
  • RangeError,当函数实参越界时发生,如ArrayNumber.toExponential,Number.toFixedNumber.toPrecision时入参非法时。
  • ReferenceError,当引用未声明的变量时发生
  • SyntaxError,解析时发生语法错误
  • TypeError,当值不是所期待的类型时,null.f()也报这个错
  • URIError,当传递一个非法的URI给全局URI处理函数时发生,如decodeURIComponent('%'),即decodeURIComponentdecodeURI,encodeURIComponentencodeURI

三.动手写自己的异常类型吧!

关于在StackOverflow上早有人讨论如何自定义异常类型了参考
于是我们顺手拈来即可

function MyError(message, fileName, lineNumber){
  if (this instanceof MyError);else return new MyError(message, fileName, lineNumber)
  this.message = message || ""
  if (fileName){ this.fileName = fileName }
  if (lineNumber){ this.lineNumber = lineNumber }
}

var proto = MyError.prototype = Object.create(Error.prototype)
proto.name = "MyError"
proto.constructor = MyError

四.捕获“同步代码”中的"运行时异常",用try/catch就够了

为了防止由于异常的出现,导致正常代码被略过的风险,我们习惯采取try/catch来捕获并处理异常。

try{
  throw Error("unexpected operation happen...")
}
catch (e){
  console.log(e.message)
}

很多时我们会以为这样书写就万事大吉了,但其实try/catch能且仅能捕获“同步代码”中的"运行时异常"

同步代码

"同步代码"就是说无法获取如setTimeoutPromise等异步代码的异常,也就是说try/catch仅能捕获当前任务的异常,setTimeout等异步代码是在下一个EventLoop中执行。

// 真心捕获不到啊亲~!
try{
  setTimeout(function(){
    throw Error("unexpected operation happen...")
  }, 0)
} catch(e){
  console.log(e)
}

运行时异常

"运行时异常"是指非SyntaxError,也就是语法错误是无法捕获的,因为在解析JavaScript源码时就报错了,还怎么捕获呢~~

// 非法标识符a->b,真心捕获不到啊亲~!
try{
  a->b = 1
} catch(e){
  console.log(e)
}

这时大家会急不可待地问:“异步代码的异常咋办呢?语法异常咋办呢?”在解答上述疑问前,我们先偏离一下,稍微挖挖throw语句的特性。

throw后面可以跟什么啊?

一般而言我们会throw一个Error或其子类的实例(如throw Error()),其实我们throw任何类型的数据(如throw 1,throw "test",throw true等)。但即使可以抛出任意类型的数据,我们还是要坚持抛出Error或其子类的实例。这是为什么呢?

try{
  throw "unexpected operation happen..."
} catch(e){
  console.log(e)
}

try{
  throw TypeError("unexpected operation happen...")
} catch(e){
  if ("TypeError" == e.name){
    // Do something1
  }
  else if ("RangeError" == e.name){
    // Do something2
  }
}

原因显然易见——异常发生时提供信息越全越好,更容易追踪定位重现问题嘛!

五."万能"异常捕获者window.onerror,真的万能吗?

在每个可能发生异常的地方都写上try/catch显然是不实际的(另外还存在性能问题),即使是罗嗦如Java我们开发时也就是不断声明throws,然后在顶层处理异常罢了。那么,JavaScript中对应的顶层异常处理入口又在哪呢?木有错,就是在window.onerror。看看方法签名吧

/**
 * @description window.onerror处理函数
 * @param {string} message - 异常信息"
 * @param {string} source  - 发生异常的脚本的URI
 * @param {number} lineno  - 发生异常的脚本行号
 * @param {number} colno   - 发生异常的脚本列号
 * @param {?Error} error   - Error实例,Safari和IE10中没有这个实参
 */

这时我们就可以通过它捕获除了try/catch能捕获的异常外,还可以捕获setTimeout等的异步代码异常,语法错误。

window.onerror = function(message, source, lineno, colno, error){
  // Do something you like.
}
setTimeout(function(){ throw Error("oh no!") }, 0)
a->b = 1

这样就满足了吗?还没出大杀技呢——屏蔽异常、屏蔽、屏~~
只有onerror函数返回true时,异常就不会继续向上抛(否则继续上抛就成了Uncaught Error了)。

window.onerror = function(){return true}

现在回到标题的疑问中,有了onerror就可以捕获所有异常了吗?答案又是否定的(我的娘啊,还要折腾多久啊~0~)

  • Chrome中对于跨域脚本所报的异常,虽然onerror能够捕获,但统一报Script Error。若要得到正确的错误信息,则要配置跨域资源共享CORS才可以。
  • window.onerror实际上采用的事件冒泡的机制捕获异常,并且在冒泡(bubble)阶段时才触发,因此像网络请求异常这些不会冒泡的异常是无法捕获的。
  • Promise.reject产生的未被catch的异常,window.onerror也是无能为力。

六.Promise.reject也抛异常,怎么办?

通过Promise来处理复杂的异步流程控制让我们得心应手,但倘若其中出现异常或Promise实例状态变为rejected时,会是怎样一个状况,我们又可以如何处理呢?

Promise是如何标识异常发生的?

Promise实例的初始化状态是pending,而发生异常时则为rejected,而导致状态从pending转变为rejected的操作有

  • 调用Promise.reject类方法
  • 在工厂方法中调用reject方法
  • 在工厂方法或then回调函数中抛异常
// 方式1
Promise.reject("anything you want")
// 方式2
new Promise(function(resolve, reject) { reject("anything you want") })
// 方式3
new Promise(function{ throw "anything you want" })
new Promise(function(r) { r(Error("anything you want" ) }).then(function(e) { throw e })

当Promise实例从pending转变为rejected时,和之前谈论到异常一样,要么被捕获处理,要么继续抛出直到成为Uncaught(in promise) Error为止。

异常发生前就catch掉

若在异常发生前我们已经调用catch方法来捕获异常,那么则相安无事

new Promise(function(resolve, reject){
  setTimeout(reject, 0)
}).catch(function(e){
  console.log("catch")
  return "bingo"
}).then(function(x){
  console.log(x)
})
// 回显 bingo

专属于Promise的顶层异常处理

若在异常发生前我们没有调用catch方法来捕获异常,还是可以通过windowunhandledrejection事件捕获异常的

window.addEventListener("unhandledrejection", function(e){
  // Event新增属性
  // @prop {Promise} promise - 状态为rejected的Promise实例
  // @prop {String|Object} reason - 异常信息或rejected的内容

  // 会阻止异常继续抛出,不让Uncaught(in promise) Error产生
  e.preventDefault()
})

迟来的catch

由于Promise实例可异步订阅其状态变化,也就是可以异步注册catch处理函数,这时其实已经抛出Uncaught(in promise) Error,但我们依然可以处理

var p = new Promise(function(resolve, reject){
  setTimeout(reject, 0)
})
setTimeout(function(){
  p.catch(function(e){
    console.log("catch")
    return "bingo"
  })
}, 1000)

另外,还可以通过windowrejectionhandled事件监听异步注册catch处理函数的行为

window.addEventListener("rejectionhandled", function(e){
  // Event新增属性
  // @prop {Promise} promise - 状态为rejected的Promise实例
  // @prop {String|Object} reason - 异常信息或rejected的内容
  // Uncaught(in promise) Error已经抛出,所以这句毫无意义^_^
  e.preventDefault()
})

注意:注意:只有抛出Uncaught(in promise) Error后,异步catch才会触发该事件。

七.404等网络请求异常真心要后之后觉吗?

也许我们都遇到<img src="./404.png">报404网络请求异常的情况,然后测试或用户保障怎么哪个哪个图标没有显示。其实我们我们可以通过以下方式捕获这类异常

window.addEventListener("error", function(e){
  // Do something
  console.log(e.bubbles) // 回显false
}, true)

由于网络请求异常不会冒泡,因此必须在capture阶段捕获才可以。但还有一个问题是这种方式无法精确判断异常的HTTP状态是404还是500等,因此还是要配合服务端日志来排查分析才可以。

参考

-- EOF --

本文标题:前端魔法堂——异常不仅仅是try/catch

本文链接:https://smohan.net/blog/kr6yu1

原文作者:肥仔John

原文链接:https://www.cnblogs.com/fsjohnhuang/p/7685144.html

本站使用「 署名-非商业性使用 4.0 国际 (CC BY-NC 4.0) 」创作共享协议,转载或使用请署名并注明出处。 相关说明 »

更多文章

评论 「 ... 」