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

我正在读一本书，其中声称（双关意图）“您应该将代码加载到Debug.Assert方法，只要您的条件始终为真或假。应该使用Debug.Assert和Debug.Fail，并且它们应该保留在生产代码中吗？

我一直没有使用这两种调试方法，但它是有道理的。然而，我不喜欢在我的生产代码库中散布这些东西。

想法？

2011-06-09 richard

这很好，因为编译器在发布版本中省略了它。这不是坏习惯，你不需要从源头上删除它们（事实上，你可能不应该）。但是你必须要小心：

Debug.Assert(SomethingImportantThatMustExecute());

是坏 - 在SomethingImportantThatMustExecute将释放被忽略;你必须使用：

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

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

2011-06-09 06:54:26

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

2011-06-09 06:49:35

我知道它会删除它们（它会删除所有符号），但我不知道这是丑陋还是不好的做法。我从你的回答中假设不是。 – richard 2011-06-09 06:52:53

@Richard DesLonde：不，实际上，这是一个很好的做法，只要它能帮助你开发出好的代码。 – 2011-06-09 06:54:55

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

2011-06-09 06:50:02 TcKs

这取决于你正在使用它。如果你在自己的方法中使用它进行断言，为了确保它们正常工作，我认为它是还行 - 但我更愿意使用单元测试来验证我所能想到的所有事情。

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

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

在这种行为应该不变化，只是因为你正在运行版本的代码我的看法。

2011-06-09 06:55:32

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

但是请事先考虑一下单元测试。如果您要测试Debug版本，则结果（关于错误逻辑）可能与您的发行版本不同。

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

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

2011-06-09 07:22:40

1+用于提及代码合同 – Marcel 2013-01-21 09:35:56

回答