小编给大家分享一下Node错误处理的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
创新互联建站-专业网站定制、快速模板网站建设、高性价比大名网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式大名网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖大名地区。费用合理售后完善，十多年实体公司更值得信赖。01 Error
JS 中的 Error 对象，包含了错误的具体信息，包括 name、message、错误堆栈 stack 等。可以以 new Error 方式创建实例抛出，或调用 Error.captureStackTrace 为已有对象添加 stack 错误堆栈信息 而后抛出。
02 错误抛出几种方式
* Throw*：Javascript 抛出的异常，是以 throw 方法抛出，未必都是 Error 的实例，但通过 nodeJs 或者 js 运行时发生的错误，都是 Error 的实例。
* EventEmitter*：Nodejs 形式的错误回调，大部分流 & 异步事件都衍生自 EventEmitter 类 || 实例，如 fs, process, stream 等。
Process：程序运行过程中抛出的异常，或由底层库抛出，或是运行中发生的一些 SyntaxError 之类。
03 错误捕获几种方式
try .. catch：常用的一种捕获错误方式，浏览器 || node 环境均适用。
缺点：只针对同步异常有效。
*EventEmitter *
由 Events 模块提供的 EventEmitter 类，基于 Observer 模式做的 publish/subscribe，通过 .on('error', ...)|| .addEventlistener('error', ...) 注册 subscriber，.emit() 发布事件，但会有大的 maxListener 的限制，可更改。
不 show 源码了，特别简单，自己去 look 一下。如 koa 的 app 就是基于 EventEmitter 的扩展，因此可以通过监听 error。
*Process *
Process 进程对象也是 EventEmitter 的实例，可通过如下两事件监听 error。
unhandledRejection ：promise 的回调报错，可通过监听该事件 catch，但要注意由于 promise 的 rejection 不知道会在啥时候才发生，所以实际上可能在 unhandledRejection 事件触发后才 catch 了这个信息，对应有 rejectionHandled 事件监听，如下：
(承上) uncaughtException ：其余 js 运行中发生 || 抛出的未捕获错误，均可通过监听该事件解决，若不进行该事件的监听，发生异常时，会直接导致程序 crash。但不建议用这种方式 catch，程序运行中的错误 更应该是抛出来，所有的 error 都 catch 的话，岂不是程序都可以看成无 bug 了。but 在打错误日志的时候是需要 catch 上报日志的，但是在上报完后，需要继续把 error throw，对于 uncaughtException callback 中抛出的异常不会再捕获，而是以非 0 的状态码 exit。
04 小结
说了这么多，就做个小小总结吧 以上关系网可以概括为如图：
个人见解，实际处理中基于几点准则：
1、对于需要具象化的错误信息，也就是我们需要知道具体是哪一块的错误，并且在错误发生时即进行个性化处理。这一类型的错误，在程序中执行时要对可能会出错的函数进行 catch，方式有多种: try ... catch（同步）； 或 通过 node 形式的标准错误回调 (err) => {...}（要求所调用的方法，支持该种写法）； 或 监听 error 事件 .on('error', err => {...})（要求所调用的对象继承自 EventEmitter 实例，并内部发生错误时，会 emit('error')）。
2、promise 形式的错误，可在 promise 实例的末尾再引入 .catch，可捕获该实例所有 then 中抛出的异常；另外 async 的引入也允许了我们可以如同步操作一样捕获错误。
3、但有时候程序的运行，不可能针对所有的函数操作等都去 try ... catch，也不能保证程序运行一定就无 bug，但必须要能够把这些异常都捕获并上报。因此 process 的两个大 boss: unhandledRejection & uncaughtException，是必须引入的，在程序最外层引入，且越靠前越好。此外针对 unhandledRejection，为防止说把不必要的 rejection 上报，可以在收到事件时，先把被 reject 的 promise 和 error 存储起来，设置时间 maxTimeout ，超过 maxTimeout 仍未收到 rejectionHandled 的 promise 事件，再上报。
koa 项目为例：
05 源码解读
下图为 node 中对于 process 的初始化等系列流程：
node.cc 其实是 node 运行主要的文件，其中定义了三个重载函数 Start，调用顺序为 3 → 2 → 1，每个函数参数不同处理不同的逻辑；
isolate->AddMessageListener 的监听事件 OnMessage 会在 js 运行发生错误时触发，嗯，是的，只有 error 才会传递 ；这很好的解释了为什么 process 监听 uncaughtException 就可以监听到所有的抛出的非 promise 异常；
OnMessage 调用了 FatalException 函数，FatalException 引用 process.fatalException 并传入 error （env 是 env.h 中声明的 Environment 类实例，fatalexceptionstring 也是其中定义的，返回值为 'fatalException'）； 以下为 FatalException 函数的部分内容。
在调用 fatalException 函数前，先调用 v8::TryCatch::setVerbose 把 verbose 设置为 false，则运行时抛出的异常就不会再触发 FatalException ；在捕获到运行错误后，把 exitcode 设为 7，并返回；这就解释了为什么在 uncaughtException 时抛出的异常不会再重新触发回调，要知道 EventEmitter 可没帮你做这样的事情。
_fatalException 在触发 "uncaughtException" 事件前其实是会优先检查 domain 是否存在，当 domain 不存在时才会调用 uncaughtException 的，但 domain 这个已经被废除了，也就不累述了。
unhandledRejection 事件的触发整体思路也差不多，首先会调用 SetupPromises 初始化，然后调用 v8::Isolate::SetPromiseRejectCallback 进行监听 ... 并且跟 uncaughtException 不同的是 unhandledRejection 的触发只会打印 warning 并不会把整个程序给 crash 了。
以上是“Node错误处理的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联成都网站设计公司行业资讯频道！
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
