前端异常类型及捕获方式

引子

最近想起这方面的事情，就去花时间查找了相关资料，以下是个人的总结。

异常类型

从使用浏览器，浏览一个网页，与网页进行交互的过程，从用户的角度想一想会出现那些异常。

首先是使用浏览器一般都是基于操作系统，系统自身可能会出现问题，比如内存不够。这类情况归为系统异常。

正常打开浏览器后，访问网页的时候，可能没有网络，或提示出现服务错误等等，这类情况归为网络异常。

能够正常访问网页后，用户进行交互时，可能出现一种情况下点击有效，另一种情况下点击无效。这类情况归为应用异常。

在上面感性的认知基础上，下面进一步进行细化。

系统异常

系统异常情况比较少，相关的可能有：

浏览器崩溃

网络异常

网络异常中，相关的可能有：

XMLHttpRequest 请求异常
Fetch 请求异常
静态资源加载异常

应用异常

应用异常可以用 JavaScript 中的错误对象体现出来：

EvalError ：与 eval() 有关的错误。
RangeError ：表示这个值不在允许值集或范围内。
ReferenceError ：表示发现一个无效的引用。
SyntaxError ：表示发生了解析错误。
TypeError ：当其它类型错误都不符合时，TypeError 用于指示一个不成功的操作。
URIError ：表示用于处理 URI 的函数（encodeURI 或 decodeURl）使用方式与其定义的不兼容。

比较常见的异常可以参考 Top 10 JavaScript errors from 1000+ projects 。

异常捕获

浏览器都具有某种向用户报告异常的机制，对于用户都是隐藏此类信息。对于开发者，一般在控制台可以看到相关信息。

下面看下捕获异常对应的方法。

try-catch 捕获

try-catch 使用的形式如下：

try {
  // 可能导致异常的代码
} catch(error) {
  // 发生异常时的处理
}

测试页面见这里，有下面的一些特点：

catch 块中会接收一个包含异常信息的对象，在不同的浏览器中包含的信息可能不同，但共同有一个保存异常信息的 message 属性。
不能捕获语法异常。
不能捕获异步异常。
该方式捕获的异常，不会出现在控制台上，也不会被 error 事件捕获。

语法异常在开发的阶段就很容易发现，例如：

try {
  var num = '333;
} catch(error) {
  console.info('try-catch：', error);
}

不能捕获异步异常示例如下：

try {
  setTimeout(() => {
    name.forEach(() => {});
  },1000)
} catch(error) {
  console.info('try-catch：', error);
}

try-catch 比较适合用在那些可以预见可能出错的地方。

error 事件捕获

通常将这个事件绑定在 window 上，但由于历史原因，使用 DOM 不同级别的绑定方式，会有些差别。测试页面见这里

DOM0 级方式

也就是使用 window.onerror 指定处理程序，其特点有：

参数有 5 个，对应含义分别为 message — 错误信息（字符串）、source — 发生异常的脚本URL（字符串）、lineno — 发生异常的行号（数字）、colno — 发生异常的列号（数字）、error — Error 对象。
函数体内用 return true 可以阻止异常信息出现在控制台。
可以捕获到异步异常。
不能捕获到语法异常。
不能捕获 try-catch 中的异常。
不能捕获 script、img、input、audio、source、track 标签元素 src 属性的加载异常（HTML5 不支持的 frame 标签不讨论）。测试页面见这里。
不能捕获 link 标签的加载异常，测试页面间这里这里。

DOM2 级方式

也就是使用 window.addEventListener 指定处理程序，其特点有：

参数对应 1 个，是一个 ErrorEvent 对象，其中包含信息相对 DOM0 级更加丰富。
函数体内用 preventDefault() 方法可以阻止异常信息出现在控制台，但如果是加载资源异常无法阻止。
可以捕获 script、img、input、audio、source 标签元素 src 属性的加载异常（track 尝试了一下不行）。由于加载请求不会冒泡，所以需要在事件的捕获阶段监听才行。但这种方式无法知道 HTTP 的相关状态。测试页面见这里。
可以捕获 link 标签的加载异常，测试页面间这里这里。
可以捕获异步异常。
不能捕获到语法异常。
不能捕获到 try-catch 中的异常。

onerror 事件比较适合捕获预料之外的异常。

Promise、Async/Await 异常捕获

Async 函数返回的总是一个 Promise ，如果 Async 函数里面有异常，Promise 会 reject 。所以统一的放到 Promise 里面的 catch 处理会比较方便。其特点：

没有写 catch 的 Promise 无法被 onerror 或 try-catch 捕获，测试页面见这里。
当 Promise 被 reject 且没有 reject 处理器的时候，会触发 unhandledrejection 事件 unhandledrejection 。
写了 catch 后，不会触发 unhandledrejection 事件，所以建议全局增加这个事件监听。
本地测试验证的时候，注意跨域的限制，见 issues1、issues2。

XMLHttpRequest 请求异常捕获

XMLHttpRequest 目前来说应用非常广泛，有对应的 error 事件可以进行监听。在实际中，有可能团队内已有约定的一套异常状态码，可根据实际情况进行对应的处理。这是简单示例。

Fetch 请求异常捕获

Fetch API 提供了一个获取资源的接口。它对于使用过 XMLHttpRequest 的人来说会很类似，但这个新的接口提供了更加强大的功能。有下面的一些点需要注意：

fetch 方法返回的是一个 Promise ，因此可以使用 catch 进行异常捕获。
当接收到一个代表错误的 HTTP 状态码时，fetch 返回的 Promise 不会 reject ，即使响应的 HTTP 状态码是 404 或 500。相反，它会 resolve ，但会将 resolve 返回值的 ok 属性设置为 false ，仅当网络故障或请求被阻止时，才会 reject 。这是请求为 404 的示例。

iframe 异常捕获

error 事件可以捕获到一些标签的 src 加载异常，但 iframe 的情况有些不一样。在网上找了一些资料，尝试了下面的一些方法：

使用 window.onerror 方式，无法捕获，这是测试页面。
使用 window.frames[0].onerror 方式，无法捕获，这是测试页面。
在标签上绑定 onerror 事件，没有触发，无法捕获，这是测试页面。
绑定 onload 事件，可以触发，但无法直接的捕获，例如一般的网站都设置了 404 页面，当 src 加载的一个网页找不到时，就会默认使用 404 网页，虽然触发了 onload 事件，但仍然不知道是不是异常。这个时候，可以通过间接的检测这个显示 404 页面的一些信息，来判断是否异常，比如当发现这个页面 title 里面有 404 或者 not found 之类的词汇，那就说明 iframe 加载异常。这个根据实际情况，可以设置其它检测的标识。这是测试页面。

还有一种思路就是用一个异步请求，让服务器端判断一下是否能够正常的访问 src 的资源，如果请求返回正常，那就直接动态设置 src 的值，否则就是异常情况，直接上报即可。

跨域

跨域的出现是由于浏览器的同源策略，一旦发生，会在控制台出现很明显的提示。通过查找资料发现，更多的方案是提前解决这个问题，但也有针对特定的情况进行捕获的方法。下面是相关的资料：