Skip to content

建立 2026-09-15 更新 2026-09-15

錯誤處理

模組會失敗：API 限流、欄位是空的、對方服務維護。預設行為常常是整次執行停住。正式流程要在容易失敗的模組上加 error handler，否則你只能在執行紀錄裡看到紅色、然後手動重跑。

錯誤處理路線在畫面上是透明虛線，接在模組下方，最後一顆才是 handler。

五種 handler 何時用

官方有五種，名稱與效果以 Error handlers 為準：

Handler 情境還繼續嗎 典型用途
Skip 這筆 bundle 丟掉，換下一筆 偶爾髒資料可接受，不要整批停
Resume 用你指定的替代輸出繼續往後跑 失敗時填預設值，後面模組仍要做
Retry（Break／未完成執行） 這筆先存成 incomplete，其餘繼續 暫時性錯誤（網路、429），稍後自動或手動重試
Commit 停止，已做的變更保留 後面步驟不該在錯誤後繼續，但前面寫入要留
Rollback 停止，並盡量還原 必須「全有或全無」的交易感流程

Skip 不會讓「同一筆失敗的 bundle」繼續走到 Router 後面。它結束的是這一個 bundle 的這次週期。只有還有下一筆 bundle 時，情境才會處理下一筆。

實務建議

  1. 對外 HTTP、寄信、第三方 CRM 優先加 handler，不要只加在穩定的內建模組。
  2. 限流（HTTP 429）用 Retry，不要用 Skip 假裝成功。
  3. 測 handler 時故意送壞資料，確認執行狀態（Success／Warning／Error）符合預期。
  4. 看不懂紅色錯誤時，可用官方的 AI 錯誤說明（產品功能，見下方影片），但仍要自己判斷該 Skip 還是 Retry。

完整觀念與評量在 Make Intermediate 的 Handling errors 課程。社群常推薦的 Error Handlers 播放清單若仍公開，可當補充；介面若已改版，以 Academy 與 Help Center 為準。

相關影音

官方示範用 AI 解讀錯誤、加速除錯。這不是取代 handler，而是看懂失敗原因的輔助。約 5 分鐘。

相關資料