关于在节点错误处理注释中挖洞的一系列教程

前言

前段时间，我不得不在项目中添加日志报告，然后我学习了如何改进节点中错误信息的收集。下面就不多说了，我们来看看详细的介绍

01错误

JS中的Error对象包含错误的具体信息，包括名称、消息、错误栈等。您可以创建一个实例以新的错误方式抛出，或者调用Error.captureStackTrace将堆栈错误堆栈信息添加到现有对象中，然后抛出它。

02错误抛出的几种方式

* throw *:JavaScript抛出的异常由throw方法抛出，这些异常不一定是error的实例，但是通过nodeJs或Js运行时出现的Errors都是Error的实例。

* event emitter *:nodejs形式的错误回调。大多数异步事件都源自eventemitter类的| |实例，如fs、process、stream等。

进程：程序运行过程中抛出的异常，或者底层库抛出的异常，或者运行过程中出现的语法错误。

03捕捉错误的几种方法

尝试.catch:捕捉错误的常用方法，适用于浏览器||节点环境。

缺点：它只对同步异常有效。

*事件发射器*

事件模块提供的事件发射器类，基于观察者模式进行的发布/订阅，通过注册订阅者。开启('错误'，) | |.addeventlistener('错误'，)，并通过发布事件。emit()，但会有maxListener最大的限制，可以更改。

不要显示源代码。很简单。去找你自己。例如，koa的应用程序是基于EventEmitter的扩展，因此它可以监控错误。

*流程*

Process process对象也是EventEmitter的一个实例，它可以通过以下两个事件来监控错误。

unhandledreprojection:promise的回调报告了一个错误，可以通过监视事件来捕获该错误。但是，需要注意的是，由于拒绝承诺不知道何时会发生，因此在触发未处理的拒绝事件后，实际上可能会捕获到此信息，相应的rejectionHandled事件将按如下方式进行监控：

UncaughtException:由| |引发的未捕获错误发生在其他js操作中，可以通过监控事件来解决。如果事件没有被监控，异常将直接导致程序崩溃。但是，不建议这样抓。应该排除程序运行中的错误。如果所有的错误都被发现，那么这个程序就可以被认为是没有错误的。但是需要catch来报告错误日志，但是在报告之后，需要继续抛出错误，并且在uncaughtException回调中抛出的异常不会被再次捕获，而是以非零状态码退出。

04总结

说到这里，让我们做一个小小的总结。以上网络可以总结如下图所示：

个人观点，基于实际处理中的几个标准：

1.对于需要可视化的错误信息，也就是我们需要知道具体是哪个错误，并在错误发生时进行个性化处理。当在程序中执行这种类型的错误时，有必要捕获可能出错的函数。方法有很多：试试.catch(同步)；或者通过标准错误回调(err)={来实现.}以节点的形式(需要调用的方法来支持这种编写)；或者听听错误事件。on('错误'，err={.})(当被调用的对象从EventEmitter实例继承并且发生内部错误时，会发出(“‘错误’”)。

2.对于承诺形式的错误。catch可以在promise实例的末尾引入，它可以捕获所有实例中抛出的异常；此外，异步的引入还允许我们捕捉同步操作等错误。

3.然而，有时当一个程序运行时，它是不可能尝试的.catch适用于所有函数操作，并且不能保证程序运行时没有bug，但是它必须能够捕获并报告这些异常。因此，两个大BOSS :未处理的拒绝进程的未排除必须在程序的最外层引入，越靠前越好。此外，对于unhandledRejection，为了防止不必要的拒绝被报告，当收到事件时，先存储被拒绝的承诺和错误，设置时间maxTimeout，在maxTimeout之后报告rejectionHandled承诺事件。

以koa项目为例：

05源代码解释

下图显示了一系列流程，如节点中的流程初始化：

其实node.cc是节点操作的主文件，其中定义了三个重载函数Start，调用顺序为3 2 1，每个函数参数处理不同的逻辑；

当js错误运行时，会触发isolate-AddMessageListener的监听事件OnMessage，嗯，是的，只会传递错误；这就解释了为什么进程可以通过监听uncaughtException来监听所有抛出的非承诺异常。

OnMessage调用宿命论异常函数，宿命论异常引用process .宿命论异常并传入错误(env是env.h中声明的Environment类实例，其中也定义了宿命论异常字符串，返回值为‘宿命论异常’)；下面是宿命论异常函数的一部分。

在调用宿命论异常函数之前，先调用v8: try catch :3360设置verbose为false，那么运行时抛出的异常不会再次触发宿命论异常；捕获运行错误后，将exitcode设置为7并返回；这就解释了为什么uncaughtException中抛出的异常不会再次触发回调，因为EventEmitter不能为你做这样的事情。

_宿命论异常实际上是在触发‘unochistorexception’事件之前优先检查域是否存在，只有当域不存在，但域已经被废除时才会调用unochistorexception，所以不会重复。

触发unhandledRejection事件的整个想法是相似的。首先，将调用SetupPromises进行初始化。然后调用v 8: isolate : setprobleserejectcallback进行监控.而且与unhandledRejection不同，unhandledRejection的触发器只会打印警告，不会让整个程序崩溃。

06 END

参考网站：https://v8.paulfryzel.com/docs/master/index.html

摘要

以上就是本文的全部内容。希望本文的内容对大家的学习或工作有一定的参考价值。有问题可以留言交流。谢谢你的支持。