說到錯誤處理就會想到錯誤碼的部分，我們團隊針對錯誤碼的命名進行規範，避免未來錯誤碼增加的時候遇到命名困境。

錯誤碼格式

一般來說，我們可以有兩種命名格式
資源優先

E_USER_NOT_FOUND
E_USER_DUPLICATED
E_USER_LOGIN
E_ORDER_CREATED
E_PAYMENT_CREATED

事件優先

E_NOT_FOUND_USER
E_NOT_FOUND_ORDER
E_CREATE_USER
E_CREATE_ORDER

我們採用前者，也就是資源優先的模式，意即規則：E_{RESOURCE}_{ERROR_NAME,ACTION_NAME}。因為我們團隊有習慣統一的 resource，像是 payment, order, member 等等，因此我們想要搜尋的時候可以很快的搜尋：E_{RESOURCE}，就能找到錯誤碼的位置。

紀錄錯誤的方式

除了錯誤碼之外，我們統一使用 sendLog() 的 wrapper 來打包相關 log，不直接使用 console.log，因為有些時候我們會需要寄送信件、傳到錯誤監控軟體、送到 Discord 等等，使用一個 utility function 來包裝起來可以讓錯誤發生時的處理更加細緻。