一般我們在做程式開發時，如果沒有特別做錯誤處理，可能會遇到一個狀況是，
程式跑一跑 -> 阿報錯了 -> 程式被迫中止了
然後就沒有然後了，我們就必須去看錯誤訊息去進行錯誤排解，這在使用者進行開發的時候是很正確的，因為我們必須知道錯誤訊息知道哪裡錯誤才能順利解決這個bug，但這樣的處理方式前提是「此時此刻有人在看、有時間立刻修」。
但有沒有可能有其他狀況呢? 有的~ 例如我上線的這個流程會固定每天8:00am開始執行，它會自動去公司EMAIL信箱做信件裡的檔案下載跟歸檔，但當其中一封信檔案下載失敗時，不能馬上中斷我的流程因為這類錯誤屬於「單筆資料失敗」，而不是「整個流程設計錯誤」。後面可能還有1000封需要去處理，遇到下載失敗的問題時我想要做的是寄信通知我哪一個信件下載失敗了，才能在這個流程跑完後另外做後續錯誤排除。
來做個流程比較圖
原本: 讀取信件 -> 檢查是否有附件檔案需要下載 -> (有)下載檔案 -> 歸檔到目標路徑
加上錯誤處理: 讀取信件 -> 檢查是否有附件檔案需要下載 -> (有)下載檔案 -> 遇到下載失敗時 -> 寄信通知我，處理哪封公司信件時發生問題 -> 先繼續處理下一封公司信件直到跑完。
這樣的設計，讓流程從「遇錯即停」變成「可預期地失敗、但不中斷整體任務」(非常重要)。而這樣的錯誤處理功能在實務上也是非常常見以及被拿來使用，當我們流程發生錯誤時只要希望能捕獲到這個錯誤並且在這個錯誤上做額外處理並且不中斷，就會使用這樣的方式做處理。
在RPA工具中，Uipath有直接的Try-Catch語法區塊可以直接方框出來使用，而在Power Automate中錯誤處理並不是一個獨立拉出來的區塊，而是藏在區塊中「附加在每一個動作上的設定」。
例如這個將文字轉換為數字的功能區塊，左下角有一個錯誤時，即是拿來做錯誤處理的功能(圖一)
圖一
點進來之後會看到有重試原則、所有錯誤、進階可以設定錯誤處理，錯誤處理的方式可以有很多種，我這邊也舉一個例子來描述這個問題，並且分析這個問題要怎麼做後續處理可以減少中斷的發生。一樣以將文字轉換為數字這個功能來做舉例:
在文字轉換成數字時出錯代表: 文字不能被轉為數字，這個字串本身可能是中文、英文、其他特殊符號。被轉為數字後的流程本來是要做計算，但當它無法被轉換，
此時可以做(圖二)的處理:
1. 使用加入新規則
2. 把這個變數的值先改成數字0
3. 移至下一個動作
圖二
在這個流程中，轉換失敗代表「這筆資料無法參與計算」，因此將其視為 0，比直接中斷整個流程來得更符合實務需求。之後繼續往下做其他流程，當然最好的錯誤處理方式是要依照業務邏輯去制定做到最有效的處理!
在Power Automate錯誤處理中，還有其他選項，例如如果要做re-try可以設定重試原則裡面的次數。
而在所有錯誤選項中，新規則可以選擇: 指定變數(我上面選的處理方式)、執行子流程
例外處理模式也可以選擇: 移至下一個動作、重複動作、移至標籤
補充:
需要注意的是，錯誤處理並不代表把所有錯誤都忽略掉，而是先讓流程跑完，再集中處理錯誤。遵照著這樣的哲學: 捕獲錯誤、記錄資訊、不中斷 → 可追蹤、後續統一排除。
但是如果遇到核心錯誤（例如關鍵主檔讀取失敗），那就不應該繼續流程，而是直接中止並通知。
- 致命錯誤（Fatal Error） → 該中止
- 可容忍錯誤（Recoverable Error） → 該記錄、跳過、繼續
延伸思考：錯誤處理的目標不是「不報錯」，而是「可控失敗」
成熟的自動化，不是讓流程永遠不出錯，而是讓錯誤出現時仍然可預期、可追查、可恢復。
然後把「可控」拆成三件事：
- 可追查：log 有 run_id、哪一步、哪封信、錯誤訊息/截圖
- 可恢復：流程有做好最後 cleanup（關檔、關視窗）避免下次卡死 (開啟EXCEL最後要關閉才不會有下次卡死或檔案壞掉的情況!)
- 可排除：錯誤清單能用來重跑（重跑就只需跑失敗的那幾筆），並視這次情況加上這次錯誤處理，減少下次流程錯誤次數，達到正向循環。
