18

这不是一个真正的“问题”，所以我将其设为 CW。

这

assert

关键字很棒！

它应该让你对自己编写的代码更有信心，但是，直到今天我创建一个小型测试类（< 20 行）时，我才意识到自从它被引入以来就再也没有使用过它。

见鬼！我几乎不使用确实非常有用的记录器，但直到今天我才意识到我不使用断言。

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

4

16 回答 16

14

早在 90 年代，我就被教导要使用很多断言，它们非常有意义。这是很好的防御性编码。

然而，我认为这已经被单元测试所取代，单元测试实际上强制代码运行并告诉它在哪里被破坏。调试断言需要有人实际运行调试代码并查看 ui 或日志。单元测试可以自动执行此操作。

于 2009-07-30T18:31:05.277 回答
14

我一直在使用它们。它们是实践“早早崩溃”理念的好方法，最好解决断言失败的原因，而不是必须处理错误/损坏的输出。

问题是你必须让它成为一种习惯。我很少在其中看到任何中间立场，人们要么不习惯它并且几乎从不使用它们，要么人们使用它们并且它们在整个代码中被严格地乱扔。你只需要进入注意到“哦，嘿，我在这里隐含假设，让我明确地确认它'断言（假设）'”的心态

于 2009-07-30T18:33:42.180 回答
11

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

我在 Code Complete 或 Effective Java 中读到它——断言应该用于检测编程错误——异常应该用于处理异常但可能的情况。如果您知道值不会为空（如合同所定义），则无需检查代码中每个方法的空值，但如果值不为空值，则断言没有坏处。仅当您为 VM 指定参数 -ea 时才会启用断言，如果禁用，它们不应影响应用程序的性能。

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

于 2009-07-30T19:36:37.373 回答
4

引入单元测试后，断言的唯一真正用途是将方法的不变量传达给其他程序员。在实际代码中执行此操作比在他们无论如何都会忽略的注释中执行此操作要好得多。很难忽略一个断言！

于 2009-07-30T21:11:35.747 回答
4

简短的回答 - 是的。

长答案 - 不总是，但经常。我通常对错误使用断言，因为我知道我无能为力（在程序运行时）并且实际上并不需要日志记录。例如 - 如果我必须检查某个值是否超出范围，或者指针是否为 NULL，即使它应该具有某个值。

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

我非常同意法莱娜的观点，你真的应该注意这一点——“嘿！我在这里做一些假设”

于 2009-07-30T18:42:09.323 回答
3

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

但是，如果你真的需要这个，一些库有你可以调用的断言静态方法，这些方法不会被跳过——这些也更具可读性，因为 assert 关键字不常见并且可能立即导致“wtf”时刻，但是 Assert .x 方法只是可以追踪的方法。特别是 Spring 框架使用了一个断言库。

于 2009-07-30T18:40:06.723 回答
2

是的，我一直使用断言，基本上每当我做出以下假设时：

  1. 可以用一个相当简单的谓词来检查。
  2. 仅仅通过阅读附近的代码显然不是真的。

但是，对于可能对性能产生微不足道影响的断言，我使用enforceD 编程语言标准库中的函数而不是assert. assert除了它保持在发布模式之外，这基本上与它的作用相同。对于更昂贵的断言，我使用assert从发布模式构建中剥离的 .

于 2010-02-15T01:05:48.790 回答
2

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

于 2009-07-30T18:26:23.927 回答
2

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

于 2009-07-30T23:21:12.630 回答
2

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

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

如果断言失败，则意味着我需要重新评估我的假设并更新代码以处理我在编写当前版本时没有想到的新奇输入。有什么不喜欢的？

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

于 2009-07-31T14:11:47.617 回答
1

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

于 2009-07-30T18:42:37.700 回答
1

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

于 2009-07-30T19:57:24.557 回答
0

我倾向于不使用它们，尽管我也不知道为什么。

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

于 2009-07-30T18:28:03.457 回答
0

不，但等不及了。我曾经用junit对所有东西进行单元测试，但那是学校，小项目没有压力。我现在在现实生活中，我应该昨天完成这段代码......

于 2009-07-30T23:15:59.443 回答
0

不，我不使用它们。

我被教导，断言不应该在“生产”代码中使用，并且在我开始使用无论如何我必须删除的东西之前 - 根据我所学到的 - 我坚持使用例外来验证条件。

于 2009-07-30T19:46:07.713 回答
0

我从来没有使用过它们，但是我在调​​试我的最后一个程序时度过了一段糟糕的时光，并且有一次记录了变量为空或不包含我期望的值的情况。一旦我完成了所有工作，我就断言了我的程序成功运行所需的一切。

于 2009-07-30T19:54:08.197 回答