在鈦坦那邊花了蠻多時間把產品架構面的 error handling 機制弄好，不再是到處 try/catch 只寫 log return false.
不再是無謂的 try/catch re-throw exception.
不再是 catch(ex) throw ex; 的該死寫法。甚至吃掉 exception 不做事的情況。
該記 log 的只在邊界層，透過 decorator/action filter/middleware 來封裝與加載。也不再有那種 log 只記到表層的 call stack 而沒記錄到 inner exception 真正的問題發生點。
該做 error handling 或附加 run time 的資訊，handle 完 re-throw 自定義的 custom business exception, 再交給 error handling 底層來觸發對應的 error handler。
在發現問題（例外）的第一時間點 throw exception 通知整個 process 發生了什麼問題。
整個 call stack 與方法簽章都是乾乾淨淨的「正常流程」，沒有不必要的 return true/false 來通知是否有異常，也沒有不必要的 error code Enum 來一路傳遞回呼叫端。
發生怎樣的異常，該決定怎樣的 error code/status code 通知呼叫端，是最後要回傳結果那一層的 error handle 職責與行為。
Error handling 本身就是一整門學問，能在企業等級產品架構裡面打好這段基礎，可以指數性降低 application design 的複雜度。
鈦坦的產品工程師扛霸子之一的 Jrting ，開始把這門知識整理成系列文了，希望能給大家一些幫助。
https://medium.com/@neokn/exception-%E6%80%8E%E9%BA%BC%E4%B8%9F%E6%89%8D%E4%B8%9F%E5%BE%97%E6%BA%96-a385bd27ed15
error code定義 在 Error Code 錯誤碼該如何設計(上) - 為什麼你不該隨意定義 的相關結果
不廢話，先來講講常見令人頭疼的錯誤碼定義方法，可以大致分為以下: 大雜燴的流水編號法– 新手天賦技能; 一碼多解釋的通靈大法– 被程式耽誤的通靈王. ... <看更多>