“使用抛异常的方式返回校验不通过的结果”是不是一个好的处理方式？

[STtree]

我正在写一个 Express 服务，其中有个地方需要校验用户的输入。我的处理是在校验不通过后抛出一个异常，由全局的异常处理来返回 400 响应。我的同事觉得我这种处理方式不行，他的理由如下:

• try catch 会增加性能开销
• exception 应该用于 error handling

我觉得有些道理，但是我之前写 Java 的时候看到过很多这种用法，而且我觉得这种用法写起来也比较方便。难道这真的不是一个好的处理方式？

[xiaoHuaJia]

其它我不知道，我一直这么写爽是真的爽。全局捕获就完事了

[xubeiyou]

都这么处理的吧 底层框架很多也这么写的

[Aresxue]

try catch 确实会会增加一些开销，主要是在 java.lang.Throwable#fillInStackTrace()中会去爬取堆栈，但参数校验这个场景下不用纠结—抛异常是综合起来性价比最高的方式，jdk 其实有 java.lang.Throwable#Throwable(java.lang.String, java.lang.Throwable, boolean, boolean)这样一个构造器去构造不需要爬栈的异常（部分场景下只依赖异常类型而不关心堆栈），但不知道为什么并没有开放出来，后续如果能开放出来搭配这个场景应该是最优解。

[shawnsh]

try catch 可能不是性能洼地

[iOCZ]

据我所知 try catch 的代码在指令层面每执行一条就要去检查状态寄存器异常标志位是否被设置。我觉得这个开销其实还好。

[itechnology]

我感觉这两个理由实在是太牵强了。我们公司就是“使用抛异常的方式返回校验不通过的结果”，自定义了一个 businessException ，入参是错误码，由全局异常处理来根据错误码返回对应的错误信息给用户。

[lesismal]

明明是 golang 的 if err 更适合错误处理、鲁棒性，一帮习惯了 java 的人喷 golang if err 。

[aguesuka]

好歹换成 Haskell 吧, 21 世纪了还在用 sum type 代替 product type

[naivety]

好用，但是如果属于经常触发，还是建议有替代方案

[IvanLi127]

后端处理不了用户请求，可不就是遇到了异常情况。很多表单验证的库，验证不通过也是抛异常出来的。当然他们也有可选用 boolean 来标记是否通过验证。
性能问题基本可以忽略不计吧。如果是牺牲可读性来换这点性能，那咋还用 js 呢，不得换语言先。
我认为抛异常还是手动判断只是风格问题，他说的理由我感觉就是在扯淡。

[thynson]

我是主张用异常的。
如果为了性能，自定义的业务异常类可以避免捕获调用栈，生成调用栈的性能开销是极大的。