应该自由使用Debug.Assert和Debug.Fail，它们应该留在生产代码中吗？

Question

我正在读一本断言（双关语）的书“你应该用 Debug.Assert 方法加载你的代码，只要你有条件永远是是真还是假。“

我没有使用过这两种调试方法，但它有一定道理。但是，我不愿意在我的生产代码库中散布这些东西。

思想？

Answer 1

没关系，因为编译器在发布版本中省略了它。这不是一种不好的做法，你不需要从源代码中删除它们（事实上，你可能不应该这样做）。但是 必须 要小心：

Debug.Assert(SomethingImportantThatMustExecute());

错误 - 版本中将忽略SomethingImportantThatMustExecute;你必须使用：

bool result = SomethingImportantThatMustExecute()
Debug.Assert(result);

基本上，避免在调用条件方法和部分方法时出现副作用。

Answer 2

这取决于你使用它的目的。如果你在自己的方法中使用它进行断言，为了确保它们正常工作，我认为它是好的 - 但我更喜欢单元测试来验证我能想到的一切，如果有的话可能的。

一个好主意（IMO）用它来验证传入输入 - 例如参数。在这种情况下，我认为以正常方式使用异常会更加一致：

if (foo == null)
{
    throw new ArgumentNullException("foo");
}

在我看来，这种行为应该不只是因为你正在运行发布代码而改变。

Answer 3

如果编译Release版本（使用Visual Studio项目设置），将自动删除所有Debug.Assert语句。所以是的，大量使用它们。

Answer 4

是的，断言很好。请注意，它们不仅是逻辑检查（这很明显），而且还可以作为一种文档形式，比评论更可靠。

但请事先考虑单元测试。如果您要测试Debug构建，结果（关于错误逻辑）可能与您的Release版本不同。

对于要在发布版本中处于活动状态的检查，可以使用Trace.Assert（）。

还没有人提到Code Contracts，这是一种更丰富，更结构化的检查和记录代码的方式。

Answer 5

您可以在生产代码库中大量使用Debug.Assert。 Debug.Assert饰有ConditionalAttribute。如果在“realease”配置中编译代码，编译器将跳过调用Debug.Assert。