在开发时你们有使用 Spring 的 Assert 工具类的习惯吗？

[grittiness]

写接口的时候，特别是入参多的时候很烦要 if 一堆逻辑判断入参是否正确，我就在公司项目都使用了 Spring 自带的 Assert 工具类，感觉比一堆 if 判断省事太多。。

今天同事偶然看到了我写的这部分代码，就跟我说平常不要用 Assert，这是测试时候用不是开发上线用。然后还表达了说这个工具类是抛 RuntimeException 会影响性能之类的说法。


我自己是认为通过这个工具类校验能节省很多 if 校验代码，Spring 的 Assert 也跟 JDK 里面测试用的 assert 也没啥关系，但是不知道用异常方式处理对性能的影响能有多大


感觉这样很尴尬，为了避免同事意见，是不是还是换回一堆 if 判断更合适？😂

[Asens]

试试 fluent-validator

[arrow8899]

assert 没毛病，符合 FailFast 理念，if 太多，容错性虽然好了，但是出了问题不好查原因

[lihongjie0209]

那就用 guava 的 precondition

[chendy]

一堆 if-else 不可取，很多库都有封装这种参数校验 /断言的功能，不满足需求的话就自己封装一些
另外一说还有 jsr-303 可用
再另外一说 Assert 是测试用的不是上线用的怕不是对 Assert 有什么误解

[Cbdy]

我认为用 Assert 是个好习惯
类似的比如 Guava 的 Preconditions，JDK 的 Objects::requireNonNull
看各大框架源代码基本已经是公认的最佳实践了，异常情况抛异常，Happy path 处理逻辑，比 Golang 的 if err != nil 不知道高到哪里去

[Takamine]

请问一下用了 Assert 之后抛出响应异常之后是怎么处理的。

[Takamine]

@Takamine 响应=>相应。

[Cbdy]

@Takamine 库、组件让调用方处理，应用让用户处理
比如：Assert.hasText(searchConditon, "请输入合法搜索条件！");

[qwerthhusn]

抛 RuntimeException 确实非常效率低，但是也是建立在有大量异常抛出的情况下，如果这种情况发生了，只能说明这程序有 BUG。。
有些框架使用 fail-fast。几乎都是用的 Assert。这时候他们会用自定义的 Assert，跑出来的异常类重写了 fillInStackTrace 方法直接 return this，这样异常也变得没那么慢了，坏处就是没有了异常堆栈

[grittiness]

@Cbdy 其实现在是要不要和其他同事统一的问题了，现在就显得你很另类的一样，就你一个人用 Assert。

我是不想用一堆 if 的，用 Assert 还有一个理由是在 Service 里面封装了两三层逻辑后，发现流程有问题要返回失败信息给前端的时候，我只能想到用 Exception 的方式来处理，要不然一层一层 return 再判断是否继续，这样的逻辑写起来就感觉很难受。

不过我是新人，入职不到一年，然后同事是好几年的老员工，我感觉也不好对同事反驳什么😂

[warcraft1236]

validator 啊

[grittiness]

@Takamine 因为是前后端分离项目，我是直接用 Spring 的全局异常处理方式，实现 HandlerExceptionResolver 以后把异常信息转 JSON 返回前端

[grittiness]

@qwerthhusn 学习到了，我以后去尝试一下这样的异常处理方式，谢谢

[bobuick]

参数校验稍微多一点的话, 用 assert 其实算不上方便, validator 吧.
另外这么用是没毛病的, failfast 原则. if 一大堆才是有毛病, 写个 web 还讲究到 jvm 的异常性能级别了, 你以为你在写 OS 呢, 做什么层级的工作考虑什么层级的事. crud 就是要讲究可读和可维护性, 这点破性能还不够塞牙缝的, 而且异常既然叫异常就是偶尔才会发生的

[BBCCBB]

该用的时候就用, 99.9%的情况不需要考虑 Assert 带来的性能影响.

[luozic]

用了 spring 了还在乎这点性能？

[sampeng]

lz，不要把工龄当回事。很多人是把 1 年的事重复做 N 年。如果你不想这样。按自己的想法走

[Jrue0011]

if/else 和 Assert 其实目的都不一样吧。。。参数在这个场景下是必须的就用 Assert 或者 Objects.requireNonNull()，不是必须的就用 if/else 或者 Optional