Node錯(cuò)誤處理的示例分析-創(chuàng)新互聯(lián)

小編給大家分享一下Node錯(cuò)誤處理的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比大名網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式大名網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋大名地區(qū)。費(fèi)用合理售后完善，十多年實(shí)體公司更值得信賴。

01 Error

 JS 中的 Error 對(duì)象，包含了錯(cuò)誤的具體信息，包括 name、message、錯(cuò)誤堆棧 stack 等。可以以 new Error 方式創(chuàng)建實(shí)例拋出，或調(diào)用 Error.captureStackTrace 為已有對(duì)象添加 stack 錯(cuò)誤堆棧信息 而后拋出。

02 錯(cuò)誤拋出幾種方式

* Throw*：Javascript 拋出的異常，是以 throw 方法拋出，未必都是 Error 的實(shí)例，但通過 nodeJs 或者 js 運(yùn)行時(shí)發(fā)生的錯(cuò)誤，都是 Error 的實(shí)例。

* EventEmitter*：Nodejs 形式的錯(cuò)誤回調(diào)，大部分流 & 異步事件都衍生自 EventEmitter 類 || 實(shí)例，如 fs, process, stream 等。

 Process：程序運(yùn)行過程中拋出的異常，或由底層庫(kù)拋出，或是運(yùn)行中發(fā)生的一些 SyntaxError 之類。

03 錯(cuò)誤捕獲幾種方式

try .. catch：常用的一種捕獲錯(cuò)誤方式，瀏覽器 || node 環(huán)境均適用。

缺點(diǎn)：只針對(duì)同步異常有效。

*EventEmitter *

由 Events 模塊提供的 EventEmitter 類，基于 Observer 模式做的 publish/subscribe，通過 .on('error', ...)|| .addEventlistener('error', ...) 注冊(cè) subscriber，.emit() 發(fā)布事件，但會(huì)有大的 maxListener 的限制，可更改。 

不 show 源碼了，特別簡(jiǎn)單，自己去 look 一下。如 koa 的 app 就是基于 EventEmitter 的擴(kuò)展，因此可以通過監(jiān)聽 error。

*Process *

Process 進(jìn)程對(duì)象也是 EventEmitter 的實(shí)例，可通過如下兩事件監(jiān)聽 error。

unhandledRejection ：promise 的回調(diào)報(bào)錯(cuò)，可通過監(jiān)聽該事件 catch，但要注意由于 promise 的 rejection 不知道會(huì)在啥時(shí)候才發(fā)生，所以實(shí)際上可能在 unhandledRejection 事件觸發(fā)后才 catch 了這個(gè)信息，對(duì)應(yīng)有 rejectionHandled 事件監(jiān)聽，如下：

(承上)  uncaughtException  ：其余 js 運(yùn)行中發(fā)生 || 拋出的未捕獲錯(cuò)誤，均可通過監(jiān)聽該事件解決，若不進(jìn)行該事件的監(jiān)聽，發(fā)生異常時(shí)，會(huì)直接導(dǎo)致程序 crash。但不建議用這種方式 catch，程序運(yùn)行中的錯(cuò)誤 更應(yīng)該是拋出來(lái)，所有的 error 都 catch 的話，豈不是程序都可以看成無(wú) bug 了。but 在打錯(cuò)誤日志的時(shí)候是需要 catch 上報(bào)日志的，但是在上報(bào)完后，需要繼續(xù)把 error throw，對(duì)于 uncaughtException callback 中拋出的異常不會(huì)再捕獲，而是以非 0 的狀態(tài)碼 exit。

04 小結(jié)

說(shuō)了這么多，就做個(gè)小小總結(jié)吧  以上關(guān)系網(wǎng)可以概括為如圖：

個(gè)人見解，實(shí)際處理中基于幾點(diǎn)準(zhǔn)則：

1、對(duì)于需要具象化的錯(cuò)誤信息，也就是我們需要知道具體是哪一塊的錯(cuò)誤，并且在錯(cuò)誤發(fā)生時(shí)即進(jìn)行個(gè)性化處理。這一類型的錯(cuò)誤，在程序中執(zhí)行時(shí)要對(duì)可能會(huì)出錯(cuò)的函數(shù)進(jìn)行 catch，方式有多種:  try ... catch（同步）；  或 通過 node 形式的標(biāo)準(zhǔn)錯(cuò)誤回調(diào) (err) => {...}（要求所調(diào)用的方法，支持該種寫法）；  或 監(jiān)聽 error 事件 .on('error', err => {...})（要求所調(diào)用的對(duì)象繼承自 EventEmitter 實(shí)例，并內(nèi)部發(fā)生錯(cuò)誤時(shí)，會(huì) emit('error')）。

2、promise 形式的錯(cuò)誤，可在 promise 實(shí)例的末尾再引入 .catch，可捕獲該實(shí)例所有 then 中拋出的異常；另外 async 的引入也允許了我們可以如同步操作一樣捕獲錯(cuò)誤。

3、但有時(shí)候程序的運(yùn)行，不可能針對(duì)所有的函數(shù)操作等都去 try ... catch，也不能保證程序運(yùn)行一定就無(wú) bug，但必須要能夠把這些異常都捕獲并上報(bào)。因此 process 的兩個(gè)大 boss:  unhandledRejection & uncaughtException，是必須引入的，在程序最外層引入，且越靠前越好。此外針對(duì) unhandledRejection，為防止說(shuō)把不必要的 rejection 上報(bào)，可以在收到事件時(shí)，先把被 reject 的 promise 和 error 存儲(chǔ)起來(lái)，設(shè)置時(shí)間 maxTimeout ，超過 maxTimeout 仍未收到 rejectionHandled 的 promise 事件，再上報(bào)。

koa 項(xiàng)目為例：

05 源碼解讀

下圖為 node 中對(duì)于 process 的初始化等系列流程：

node.cc 其實(shí)是 node 運(yùn)行主要的文件，其中定義了三個(gè)重載函數(shù) Start，調(diào)用順序?yàn)?3 → 2 → 1，每個(gè)函數(shù)參數(shù)不同處理不同的邏輯；

isolate->AddMessageListener 的監(jiān)聽事件 OnMessage 會(huì)在 js 運(yùn)行發(fā)生錯(cuò)誤時(shí)觸發(fā)，嗯，是的，只有 error 才會(huì)傳遞 ；這很好的解釋了為什么 process 監(jiān)聽 uncaughtException 就可以監(jiān)聽到所有的拋出的非 promise 異常；

OnMessage 調(diào)用了 FatalException 函數(shù)，F(xiàn)atalException 引用 process.fatalException 并傳入 error （env 是 env.h 中聲明的 Environment 類實(shí)例，fatalexceptionstring 也是其中定義的，返回值為 'fatalException'）；  以下為 FatalException 函數(shù)的部分內(nèi)容。

在調(diào)用 fatalException 函數(shù)前，先調(diào)用 v8::TryCatch::setVerbose 把 verbose 設(shè)置為 false，則運(yùn)行時(shí)拋出的異常就不會(huì)再觸發(fā) FatalException ；在捕獲到運(yùn)行錯(cuò)誤后，把 exitcode 設(shè)為 7，并返回；這就解釋了為什么在 uncaughtException 時(shí)拋出的異常不會(huì)再重新觸發(fā)回調(diào)，要知道 EventEmitter 可沒幫你做這樣的事情。

_fatalException 在觸發(fā) "uncaughtException" 事件前其實(shí)是會(huì)優(yōu)先檢查 domain 是否存在，當(dāng) domain 不存在時(shí)才會(huì)調(diào)用 uncaughtException 的，但 domain 這個(gè)已經(jīng)被廢除了，也就不累述了。

unhandledRejection 事件的觸發(fā)整體思路也差不多，首先會(huì)調(diào)用 SetupPromises 初始化，然后調(diào)用 v8::Isolate::SetPromiseRejectCallback 進(jìn)行監(jiān)聽 ... 并且跟 uncaughtException 不同的是 unhandledRejection 的觸發(fā)只會(huì)打印 warning 并不會(huì)把整個(gè)程序給 crash 了。

以上是“Node錯(cuò)誤處理的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)成都網(wǎng)站設(shè)計(jì)公司行業(yè)資訊頻道！

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

分享名稱：Node錯(cuò)誤處理的示例分析-創(chuàng)新互聯(lián)
本文路徑：http://muchs.cn/article42/coephc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、移動(dòng)網(wǎng)站建設(shè)、搜索引擎優(yōu)化、域名注冊(cè)、網(wǎng)站導(dǎo)航、全網(wǎng)營(yíng)銷推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)