digiRunner Composer node-red

Composer catch 節點的完整介紹

顏綸 Lun Yan 2023/12/22 14:50:29
313

前言

如果還不知道什麼是 Composer 的朋友們,可以先參考這篇 DigiRunnerAPI組合與設計 。

該篇範例會用到之前介紹的節點,如果想深入了解這幾個節點的朋友,也可以參考以下幾篇:

Composer debug 節點的完整介紹

Composer inject 節點的完整介紹

Composer function 節點的基本介紹

Composer http request 節點的基本介紹

 

在 node-red 中,catch 節點是一個用於監控執行期間節點拋出錯誤的特殊節點,

在 API flow 內製作錯誤處理流程必不可少的一個節點沒有之一。

而接下來將會介紹 catch 節點如何設定以及分享幾個實際應用例子。

 

 

一、基本介紹

當被監控節點發生錯誤就會將資訊流傳遞到 catch 節點,其中包含被監控節點的錯誤資訊,

原先發生錯誤的流程將會被中斷,並走從 catch 節點延伸出來的錯誤處理流程。

以下是設定介面的介紹:

(1) 可以選擇監控的範圍:

所有節點:默認選項,可以監測此 API flow 的所有節點。

in same group:只會監測在同一個組 (group) 的節點錯誤,如果該 catch 節點沒有組,則會直接監測所有節點。

指定節點:只有被選擇節點的節點才會被監控。

 

(2) 按下選擇節點可以讓使用者在編輯面板直接選取,如下圖所示:

 

(3) 依節點名稱來進行搜尋。

 

(4) 也是選取節點,只有在指定節點才會出現此介面,

使用勾選來挑選要被監控之節點,如下圖所示:

 

 

二、節點參數與特性

(1) 輸出參數:

error.message (string):錯誤資訊。

error.source.id (string):引發錯誤的節點的 ID。

error.source.type (string):引發錯誤的節點的類型。

error.source.name (string):引發錯誤的節點的名稱。

如果資訊流 (msg) 已經具有 error 屬性,則將該 error 複制爲 _error。

 

(2) 如果在子流程執行期間發生了錯誤,則該錯誤將由子流程中的 catch 節點優先處理。

如果子流程中不存在 catch 節點,則該錯誤將被拋出到有使用子流程實例所在的 API flow。

 

 

三、簡單範例

(1) 監控 http request 節點錯誤

我們對 http request 節點與 catch 節點接上了 debug 節點來觀察它們的輸出狀況,

正常狀況下會是輸出到 "回傳結果" 的 debug 節點:

但如果 http request 節點並沒有填上 URL 來故意使它產生錯誤,這時使用 inject 節點觸發此流程就會出現以下訊息:

"錯誤資訊" 的 debug 節點輸出 log,但是 "回傳結果" 的 debug 節點沒有輸出,

表示 catch 節點接到了 http request 節點拋出的錯誤並輸出,而 http request 節點的流程將會中斷。

 

順帶一提,之前在介紹 http request 節點設定介面中有個:

如果勾選了,表示非 2xx 的 http status code 就也會跑進有監控此 http request 節點的 catch 節點。

 

(2) 監控 function 節點的錯誤

我們一樣對 function 節點與 catch 節點接上了 debug 節點來觀察它們的輸出狀況,

在 function 節點執行函數是這樣:

其中 msg.qqq 為 undefined,我們故意去賦予 www 值,

這時執行它將會因為無法設定 undefined 而出錯,輸出如圖所示:

function 節點也會跟著中斷。

 

(3) 一樣是監控 function 節點的錯誤,不過內部函數如下圖所示:

throw 這個命令會使 function 節點中斷,監控該節點的 catch 節點將會捕獲 throw 出來的資訊,

如下圖所示:

如果 throw 的參數是物件,則會序列化。

 

(4) 在 function 節點使用 http 模組監聽錯誤事件內使用 throw:

或是

要注意無論 throw 放在哪邊都無法被 catch 節點捕捉到,而且會使 Composer crash 並重新啟動,

因為這些 callback 和監聽事件執行的方法都不屬於 function 節點,而是屬於 http 模組的,

所以我們面對這種狀況其中一個解法是加上 try catch:

其輸出結果如下:

(5) 監控自己的錯誤處理流程 (錯誤範例)

盡量使用以上方式,萬一 function 4 節點出錯了,其資訊流又會跑回 catch 節點,

而造成無限迴圈。

借鏡以上 (5) 的錯誤例子,監控範圍選擇指定節點並且是錯誤流程以外的節點才是最優解

 

 

四、結語

catch 節點確實在錯誤處理流程扮演重要的角色,但有小部分的錯誤是 catch 節點捕捉不到,

而這小部分的錯誤大多是 function 節點產生的,如剛剛所舉的例子,

有些則是第三方的節點因為內部出錯但是沒有拋出 (throw),這種狀況 catch 節點也是捕捉不到的,

所以錯誤捕捉部分還是不能 100% 依賴此節點

 

 

五、參考文獻

(1) node-red 官方

(2) 自己

 

 

 

 

 

顏綸 Lun Yan