我曾经在我的代码中插入 java1.4 的断言结构,发现它非常实用,因为它允许我在调试时启用插入的断言并在编译时禁用它们。
我的问题是:
是否可以对 Guava 库中的现代 Preconditions.checkArgument(..) 等做同样的事情?
了解这一点很重要。我们在代码中可能有很多 guava 的前置条件检查,但大部分都是为了调试目的,当这种前置条件的数量迅速变大时,可能会影响性能。
谢谢你的想法。
我曾经在我的代码中插入 java1.4 的断言结构,发现它非常实用,因为它允许我在调试时启用插入的断言并在编译时禁用它们。
我的问题是:
是否可以对 Guava 库中的现代 Preconditions.checkArgument(..) 等做同样的事情?
了解这一点很重要。我们在代码中可能有很多 guava 的前置条件检查,但大部分都是为了调试目的,当这种前置条件的数量迅速变大时,可能会影响性能。
谢谢你的想法。
不,没有。如果您在高速行驶时真的想解下安全带,请assert
改用。
以我的经验,大多数前提条件都非常便宜——而且不太可能在现实生活中对性能产生重大影响。(而意料之外的不良数据进入您的系统并且直到它被弄乱后才被检测到的影响可能是巨大的......)
您可以将 valid4j 与 hamcrest-matchers 一起使用(在 Maven Central 上以 org.valid4j:valid4j 的形式找到)。虽然我不推荐,valid4j 是可以关掉的。
使用系统属性:-Dorg.valid4j.AssertiveProvider=disabled
或者使用服务加载器,添加一个文件 /META-INF/services/org.valid4j.AssertiveProvider 一行 org.valid4j.impl.AssertiveDisabledProvider
链接:
看看https://github.com/cowwoc/requirements.java/(我是作者)。如果断言被禁用,它会完全满足您的要求(代码被 JIT 优化掉):
assertThat(name, value).isGreaterThan(5);
我在文档底部提供了具体的性能数据。