您是否使用assert
关键字或抛出一些验证运行时异常?它给你带来了什么好处,或者为什么你觉得它不值得使用?
答案 0 :(得分:62)
如果条件为false,则Assert将抛出运行时错误(AssertionError)。断言为您提供了一种简化的方法来记录,检查和实施代码的正确性标准。这些好处是用于定义和操纵这些正确性条件的语言级钩子。如果您希望启用或禁用它们(有关于这是否是一个好主意的争论),您可以从JVM命令行执行此操作。下面的一些评论者指出,除非在调试模式下运行,否则默认情况下会禁用断言;我的做法是始终在我的包装器脚本中添加“-ea”(启用断言)。即使在性能敏感的代码中,对我来说,权衡也有利于我从断言获得的安全性/正确性。 Assertions at Oracle和API Description for AssertionError
注意预期或意外故障(异常)之间的区别(可能超出您的控制范围)和断言失败 - 断言失败记录程序员的假设,并指出错误的程序而不是意外的外部条件或预期的异常情况。 如果发生断言失败,则解释是程序员误解或错误地表达了程序,而不是其他错误或失败的来源。
在实践中,我用它来记录我所做的明显或非显而易见的假设以及我想要生成的不变量(特别是私有/内部)代码,让我自己和其他人明白这些假设的原因,它们的制作地点,以及它们是否经过验证。比同样效果的评论要好得多。这是迈向Design by Contract的一小步。
有效的Java项目#38“检查有效性参数”(Google Books,Amazon.com)提供了参数检查和断言的适当使用之间区别的有用表示。
与SO相关:(Enabling assertions in netbeans),(Assertions vs. Exceptions),(Near duplicate, asking for examples),(Badly named, but very similar content)
答案 1 :(得分:4)
答案 2 :(得分:3)
它给你带来了什么好处,或者为什么你觉得它不值得使用?
正如其他人所建议的那样,使用断言进行强制检查是一种危险的做法。
当其他开发人员使用您的库时会发生什么?或者系统管理员或高级用户忘记或者更糟糕的是,在运行时使用 -ea 标志启用断言?你失去了所有这些检查,就是这样。
断言是一种开发工具。标志的默认状态为 off 的事实是一个死的赠品。
您的应用程序中的任何功能或优势都不应依赖于断言。
作为背景,断言在C / C ++中以相同的方式使用,其中取得了特征。在C / C ++中,开发人员通常可以在编译时传入#define DEBUG ...
来启用或禁用断言。使用C / C ++生产代码通常会关闭此功能。
从概念上讲,Java也是如此。在生产中使用条件和例外。它们基本上是一回事。
答案 3 :(得分:0)
准确地说你的问题:
Assert用于验证语句的条件。
assert (some condition)
Example : assert (6 < 7) // condition pass
assert (6 > 7) // throws AssertionException here
大多数人使用assert作为String的以下用例:(但我个人不喜欢使用assert):
assert (obj != null || obj.isEmpty() || ... )
我更喜欢使用谷歌番石榴,它是干净的并且用于此目的:
Obj.isNullOrEmpty()
更多信息:http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Strings.html
答案 4 :(得分:-2)
您可以使用它在开发期间启用某些内容,然后在实际网站上完全禁用它。例如
...
assert debug("xxx");
...
static boolean debug(String format, Object... args){ print(...); return true; }
debug语句将在实时站点上增加零开销。