請問各位
小弟目前接手到新同事寫的code覺得有些問題
例如要verify前端送來的資料格式是否正確
同事的寫法都是自定義一個exception
然後if判斷是否滿足不合格的條件
是的話就塞錯誤訊息給exception
然後throw new exception
但我記得發生exception這對程式來說是需要額外的成本
而且這些資料的情況其實算是「已知」的情況不算例外
我看過覺得比較好的作法
是把verify的部份獨立成一個method
只要有不合格的條件就回傳一個字串的錯誤訊息
完全正確就回傳一個string.empty就好
我外面只要判斷回傳值是否為empty就好
不曉得同事這樣寫的方式是不是真的不好呢?
他目前看起來沒什麼特殊考量
就只是存脆驗證失敗就丟錯誤訊息而已
或是大家有什麼更好的方式呢?
謝謝

除非是系統瓶頸處，否則擲回例外是很正常的用法可以讓程式碼的例外處理更結構化，也比較容易debug但最好是能依例外狀況不同，擲回不同的例外類別。而資料處理的業務，常常會定義一個回傳的result class，裡面就會放驗證結果與錯誤訊息了。如果是包含在介面定義好的，當然就不會用擲回例外的方式去回報錯誤了。

我也都這樣寫 好處是可以把方法提取出來不喜歡的話可以參考fluentvalidation套件

verify本身的工作就是分對錯，規格內的錯誤不會用擲例外來回傳阿。有規格就照規格走阿，還有什麼好說的= =

回傳統一格式的物件，內容包含狀態碼，回傳資料，業務邏輯錯誤訊息等欄位; 既然錯誤可預期，就可以用判斷式處理後將結果加到回傳物件，不用丟exception

就寫一個 before & after method