這篇為 「幫 AspNetCore WebApi 包上自己的 response model」 的第二部分 「包裝例外」。

我將介紹如何在 ASP.NET Core Web API 中統一處理例外狀況，並將其包裝成標準化的回應格式。

我會介紹以下兩種例外資料的包裝方法：

1. 使用 UseExceptionHandler Middleware
2. 使用 IExceptionFilter 介面

在設計 web api 時，通常會想要有一個自己系統專用的標準化回應格式，我在前一份工作中因為已經有底層的前輩建立好相關的處理套件，所以一直以來都沒特別研究怎麼包裝以及自訂回應欄位。

最近在自己的練習專案中嘗試去實作相關機制，才發現原來要考慮的東西有點多，這邊我就來分享一下我的做法以及其他可以用的方式與用途。

文章預計會分為四個部分，分別為

• Part 1 : 包裝 api 回應
• Part 2 : 包裝例外
• Part 3 : 其他包裝方法與適用情境
• Part 4 : 幫自動化產生的 Swagger Example / Schema 也加上 api response 的內容

大家在使用 dotnet 或其他可以打包成功開套件做分享的程式語言時，可能都會想到一個問題

1. 現在 WebApi 那麼盛行，我該如何抉擇要使用 Web Api 還是 套件 的形式發布我的服務、功能呢？
2. 我覺得我新寫的功能好棒棒，我想發布成 nuget package 分享給團隊，但是不確定合不合適

這邊我簡單梳理一下一些需要考量的點~

我初期在公司建立地端 Kubernetes 叢集以進行 POC 時，都是使用 kubeadm 這套官方工具進行的 (我早期文章就是基於此撰寫的)。

但是當需要將 Kubernetes 拓展到其他單位時，那相對複雜的安裝與管理方式卻是第一個難以躍過的門檻。

因此，後續改用 RKE2 建立，並且導入 Rancher 進行 Kubernetes 叢集管理。從 2022 年末使用至今，由於我們公司的運用情境相對簡單，因此沒出現太多難以處理的問題。

這篇紀錄我的 RKE2 + Rancher 的安裝命令，主要內容都是依據 iThome Kubernetes Summit 2022 時我參與的 SUSE 工作坊講師提供的資訊進行調整，並適度的加上一些說明。

今天是 2023 年的最後一天，趁著今年還沒結束，來回顧一下我在今年的技術發展狀況吧~

不過，因為這一年都沒怎麼寫 blog (都靠 hackmd 紀錄筆記)，希望不要不小心把去年的事情寫成今年 XD

重構：在不影響程式碼邏輯的前提下進行程式碼修改的行為

重構行為應使用 IDE 隨附的重構命令處理，以降低人為操作的錯誤，且盡可能在進行重構前加入測試，避免重構後發生錯誤。

本文記錄我過往經驗中，對於重構的一些想法與概念，也有在上課後老師所提供的想法。