你使用断言吗？

Question

这不是一个真正的“问题”，所以我把它做成CW。

的

assert 

关键字是伟大的！

它应该让你觉得自己对你写的代码更有信心，但是直到今天，当我创建一个小测试课程时，我意识到从介绍开始就不会使用它。

哎呀！我几乎没有使用记录器，这确实非常有用，但直到今天我才意识到我不使用断言。

你使用断言？如果不是，原因是什么？

Answer 1

不，不要使用它们。不知道为什么，只是从来没有养成习惯。

Answer 2

我倾向于不使用它们，虽然我不知道为什么。

如果你进行单元测试，比如使用nUnit，那么显然你会一直使用它们来验证你的测试结果。

Answer 3

我被教导在90年代使用大量的断言，他们很有道理。这是很好的防守编码。

但是，我认为现在已经被单元测试取代，它实际上会强制代码运行并告诉代码被破坏。调试断言需要有人真正运行调试代码并查看UI或日志。单元测试可以自动执行此操作。

Answer 4

我一直都在使用它们。他们是练习“早期崩溃”哲学的好方法，更好地解决断言失败的原因，而不是必须处理错误/损坏的输出。

问题是你必须要使它成为一种习惯。我很少看到其中的任何中间立场，人们或者不习惯它，几乎从不使用它们，或者人们使用它们，并在整个代码中严格地散布。你只需要注意到注意到“哦，嘿，我默默承担一些东西，让我明确地确认它'assert（ASSUMPTION）''

Answer 5

我不使用它们。单元测试应该足以测试你的代码。此外，由于默认情况下它们被禁用，所以它们通常完全被忽略。然后他们只会倾向于用无用的断言来混乱你的代码，这些断言可以更好地表达为注释。

如果你真的需要这一点，虽然，有些库断言静态方法，你可以调用将不跳过 - 这些也是很多的可读性，因为assert关键字是不常见的，立即会引起“WTF “时刻，但Assert.x方法只是可以追踪的方法。 Spring框架特别使用了断言库。

Answer 6

简答 - 是的。

长答案 - 并不总是，但经常。我通常使用断言来解决错误，我知道我无能为力（程序运行时），并且记录并不是真正需要的。例如 - 如果我必须检查某个值是否超出范围，或者指针是否为NULL，即使它应该有一些值。

对于“解析文件”和“无法找到文件”等其他内容，我通常会抛出异常。这样我就可以记录错误并改为使用一些故障安全文件/方法。

我也挺与Falaina同意，你真的应该让一个点要注意 - “嘿！我在这里做一些假设”

Answer 7

我倾向于检查错误条件并抛出异常，而不是。原因是我希望这些条件始终被检查，即使在生产中也是如此，异常提供了更容易处理失败条件而不是断言的方式。

Answer 8

我使用断言来确保我不会在代码中引入错误。如果我知道一个值应该在一个映射中，我为此断言（使用assert关键字）。如果我知道一个参数不应该为null，那么我坚持这一点。如果我知道参数可以为null，那么我将检查它并抛出相应的异常。

我在代码完整或有效的Java中读取它 - 断言应该用于检测编程错误 - 应该使用异常来处理异常但可能的情况。如果您知道该值不会为空（按照合同定义），则不需要检查代码中每个方法的空值，但如果值不为空，则不会影响断言。仅当您为虚拟机指定参数-ea时才会启用断言，并且如果禁用，它们不会影响应用程序的性能。

您应该使用更多日志记录:-)。了解何时使用跟踪，调试和信息，并确保您记录应用程序所做的一切。当你必须弄清楚为什么某些东西在生产环境中不起作用时，它使生活变得如此简单。

Answer 9

不，我不使用它们。

我被教导过，断言不应该用在'生产'代码中，并且在我开始使用某些东西之前，我必须按照我所了解的去除 - 我坚持使用例外来验证条件。

Answer 10

我从来没有用过它们，但是我调试过我的最后一个程序的时间很糟糕，并且有一次记录变量为空或者没有包含我期望的值。一旦我完成了所有工作，我就会声明我的程序需要的所有内容才能成功运行。

Answer 11

Java断言关键字相当于一半（需要使用-ea命令行选项运行程序），所以我发现自己依赖异常而不是断言。

Answer 12

引入单元测试后，断言的唯一真正用处是向其他程序员传递方法的不变性。在实际代码中执行此操作比在他们将忽略的注释中更好。很难忽略断言！

Answer 13

不，但不能等。我过去常常用junit单元测试一切，但那是学校，小项目没有压力。我现在在现实生活中，我应该昨天完成这个代码....

Answer 14

如果你喜欢断言，你会爱上合同。它们基本上是断言延伸到更多情况的想法。

Answer 15

是的！总是！关键字是我在每种语言中最好的朋友！

没有真正的理由不使用断言，他们确保我对输入值和状态的基本假设得到支持。

如果声明失败，这意味着我需要重新评估我的假设并更新代码以处理编写当前修订时我没有想到的新奇特输入。有什么不喜欢的？

像往常一样在编程中，它是一个只有在正确使用时才具有强大功能的工具。

Answer 16

是，我使用断言所有的时间，基本上只要我在做一个假设，即：

1. 可以用一个非常简单的谓词进行检查。
2. 通过阅读附近的代码，显然不是真的。

但是，断言有可能对性能影响甚微，我用的是enforce功能在d编程语言标准库而不是assert。这与assert基本上是一样的，只是它处于释放模式。对于更昂贵的断言，我使用assert，这是脱离发布模式构建。