问题标签 [assert]

这是场景。我正在调试我自己的应用程序（C/C++），它使用了公司另一个团队开发的一些库。当我的代码生成一些极端情况时，断言失败。这很痛苦，因为断言没有正确制定，所以库函数工作正常，但我得到了所有这些中断，我只需要继续（很多因为它在一个循环中），所以我可以得到我真正感兴趣的东西. 由于其他原因，我在调试时必须使用调试版本的库。另一个团队在下一个版本之前不会修复这个问题（嘿，它可以在我们的机器上运行）。

我可以告诉调试器忽略这部分代码断言的断点吗（即它可以为我自动继续）。

最后，我有一个关于 Stack Overflow 的问题要问！:-)

主要目标是 Java，但我相信它主要与语言无关：如果您没有本机断言，您总是可以模拟它。

我在一家销售一套用 Java 编写的软件的公司工作。代码很旧，至少可以追溯到 Java 1.3，并且在某些地方，它显示... 这是一个很大的代码库，大约 200 万行，所以我们不能一次全部重构。
最近，我们将最新版本从 Java 1.4 语法和 JVM 切换到 Java 1.6，保守地使用了一些新功能，例如assert（我们曾经使用 DEBUG.ASSERT 宏——我知道assert在 1.4 中已经引入但我们没有使用它之前）、泛型（仅类型化集合）、foreach 循环、枚举等。

尽管我已经阅读了几篇关于该主题的文章，但我对 assert 的使用仍然有些不满。然而，我看到的一些用法让我感到困惑，伤害了我的常识...... ^_^ 所以我想我应该问一些问题，看看我想要纠正的东西是否正确，或者它是否违反了惯例。我很罗嗦，所以我把问题加粗了，给那些喜欢略读的人。

作为参考，我在 SO中搜索了assert java并发现了一些有趣的线程，但显然没有完全相同的重复。

• 如何避免 Java 中的“！= null”语句？多少空检查就足够了？非常相关，因为很多断言我们只是检查变量是否为空。在我们的代码中的某些地方，有空对象的用法（例如返回new String[0]），但并非总是如此。我们必须忍受这一点，至少为了维护遗留代码。
• 在Java assertions underused中也有一些很好的答案。
• 哦，SO 有理由指出我应该何时使用 Debug.Assert()？问题也相关（减少重复的好功能！）。

首先，主要问题，今天引发了我的问题：

（是的，我们使用 MS 的 C/C++ 样式/代码约定。我什至喜欢它（来自相同的背景）！所以起诉我们。）
首先，assert()表单来自DEBUG.ASSERT()调用的转换。我不喜欢多余的括号，因为 assert 是一种语言结构，而不是（不再是）函数调用。我也不喜欢return (foo);:-)
接下来，断言不在这里测试不变量，它们被用作防止错误值的保护。但据我了解，它们在这里毫无用处：断言将引发异常，甚至没有用伴随字符串记录，并且只有在启用断言的情况下。所以如果我们有-ea选项，我们只是抛出一个断言而不是常规的 NullPointerException 一个。这看起来并不是最重要的优势，因为无论如何我们都会在最高级别捕获未经检查的异常。
我是否正确地假设我们可以摆脱它们并忍受它（即让 Java 引发这种不受约束的异常）？（或者，当然，如果可能的话，测试空值，这是在其他地方完成的）。

旁注：如果我必须在上面的代码段中断言，我会针对 ci 值而不是针对 getter 执行此操作：即使大多数 getter 都经过优化/内联，我们也无法确定，因此我们应该避免调用它两次。

有人告诉，在最后一个引用的线程中，公共方法应该使用针对参数值的测试（公共 API 的使用），而私有方法应该依赖于断言。好建议。
现在，这两种方法都必须检查另一个数据源：外部输入。IE。例如，来自用户、数据库、某个文件或网络的数据。
在我们的代码中，我看到了针对这些值的断言。我总是将这些更改为真实测试，因此即使禁用断言它们也会起作用：这些不是不变的，必须正确处理。
我只看到一个可能的异常，其中输入应该是常量，例如一个数据库表，其中填充了关系中使用的常量：如果这个表被更改但相应的代码没有更新，程序会中断。
您是否看到其他例外情况？

我看到的另一个相对频繁的用法，看起来还不错：在开关的默认值中，或者在一系列 else if测试所有可能值的末尾（这些情况可以追溯到我们使用枚举之前！），通常有一个assert false : "Unexpected value for stuff: " + stuff;
Looks legal for我（这些情况不应该在生产中发生），你怎么看？（除了这里不相关的“不切换，使用 OO”建议之外）。

最后，我在这里错过了任何其他有用的用例或烦人的陷阱吗？（大概！）

大量使用单元测试是否会阻止使用调试断言？似乎在被测代码中触发的调试断言意味着单元测试不应该存在或调试断言不应该存在。“只能有一个”似乎是一个合理的原则。这是常见的做法吗？还是在单元测试时禁用调试断言，以便它们可以用于集成测试？

编辑：我更新了“断言”以调试断言，以区分被测代码中的断言与单元测试中在测试运行后检查状态的行。

这里还有一个例子，我相信它显示了困境：单元测试通过了一个受保护函数的无效输入，断言它的输入是有效的。单元测试不应该存在吗？这不是公共功能。也许检查输入会杀死性能？或者断言不应该存在？该功能受到保护而不是私有的，因此它应该检查它的输入以确保安全。

我想创建一个 SQL Select 在 MS SQL Server 2005 中进行单元测试。基本思想是这样的：

这个想法是，如果“foo”列的值是“Result”，那么我会得到一个值 true/1；如果不是，我会得到 false/0。

不幸的是，T-SQL 不喜欢这个表达式。它在等号上窒息。

是否有某种方法可以评估 SQL 选择列表中的表达式并获得可返回的结果？（或者其他实现我想要的单元测试的方法？）

编辑：3 个很棒的答案，都是围绕 CASE 构建的。我会接受 feihtthief 的，因为他的代表最少，因此最需要它。：-） 谢谢大家。

在 Windows/c++ 上，我想自定义断言对话框以永远忽略断言，因此我可以更积极地使用断言。我了解编写正确的断言宏是多么困难，并且不希望这样做，只需挂钩对话代码即可。有没有简单的方法（或简洁的技巧）来做到这一点？

关于断言宏危险的文章(googlecache)

更新：更激进 => 更频繁地使用和用于非崩溃错误。我希望能够永远忽略一个断言，所以如果一个小错误断言发生在一个循环中，它不会有效地停止我的进程。

在 C# 中，有什么区别

和

我真的很想去：（在 C++ 中）

在 C# XNA 中，他们有一个方法可以做到这一点：

有没有办法做到这一点，以便运行时给我一个有意义的完整错误，而不仅仅是“断言失败”错误？

我只需要运行 ship build 并且我需要在 release build 中的某些条件下断言以查看问题是否已解决。我该怎么做？

PHP 的 assert 语句的行为与大多数其他语言不同。

assert('return false');实际上评估字符串，然后断言其结果（假）。

它没有将参数与 true 进行比较，而是通过检查参数的额外步骤，如果它是一个评估它的字符串，则执行比较。

确实很奇怪。

我的问题不在于理解行为，我的问题是想出这种行为的正当理由，尤其是。因为你现在必须做额外的思考工作......“这是否评估为字符串？”。

经过多年使用丑陋的大 MFC ASSERT 宏，我终于决定放弃它并创建终极 ASSERT 宏。

我可以获取文件和行号，甚至是失败的表达式。我可以显示一个带有这些的消息框，以及中止/重试/取消按钮。

当我按下 Retry 时，VS 调试器会跳转到包含 ASSERT 调用的行（而不是像其他一些 ASSERT 函数那样的反汇编）。所以这一切都非常有效。

但真正酷的是显示失败的函数的名称。

然后我可以决定是否调试它，而无需尝试从文件名中猜测它所在的函数。

例如，如果我有以下功能：

然后当 ASSERT 触发时，消息框会显示如下内容：

那么，在运行时找出当前函数名称的最简单方法是什么？

它不应该使用 MFC 或 .NET 框架，即使我确实使用了这两者。
它应该尽可能便携。