请问各位
小弟目前接手到新同事写的code觉得有些问题
例如要verify前端送来的资料格式是否正确
同事的写法都是自定义一个exception
然后if判断是否满足不合格的条件
是的话就塞错误讯息给exception
然后throw new exception
但我记得发生exception这对程式来说是需要额外的成本
而且这些资料的情况其实算是“已知”的情况不算例外
我看过觉得比较好的作法
是把verify的部份独立成一个method
只要有不合格的条件就回传一个字串的错误讯息
完全正确就回传一个string.empty就好
我外面只要判断回传值是否为empty就好
不晓得同事这样写的方式是不是真的不好呢?
他目前看起来没什么特殊考量
就只是存脆验证失败就丢错误讯息而已
或是大家有什么更好的方式呢?
谢谢

除非是系统瓶颈处，否则掷回例外是很正常的用法可以让程式码的例外处理更结构化，也比较容易debug但最好是能依例外状况不同，掷回不同的例外类别。而资料处理的业务，常常会定义一个回传的result class，里面就会放验证结果与错误讯息了。如果是包含在接口定义好的，当然就不会用掷回例外的方式去回报错误了。

我也都这样写 好处是可以把方法提取出来不喜欢的话可以参考fluentvalidation套件

verify本身的工作就是分对错，规格内的错误不会用掷例外来回传阿。有规格就照规格走阿，还有什么好说的= =

回传统一格式的物件，内容包含状态码，回传资料，业务逻辑错误讯息等字段; 既然错误可预期，就可以用判断式处理后将结果加到回传物件，不用丢exception

就写一个 before & after method