到目前为止，我已经做了一年的专业软件工程师，并获得了计算机科学学位。我知道c++和C中的断言有一段时间了，但直到最近才知道它们存在于c#和。net中。
我们的生产代码不包含任何断言，我的问题是这个…
我应该开始在我们的生产代码中使用断言吗?如果可以，什么时候使用它最合适?这样做会更有意义吗
Debug.Assert(val != null, "message");
or
if ( val == null )
throw new exception("message");
当前回答
断言用于捕获程序员(您的)错误，而不是用户错误。只有在用户不可能触发断言时才应该使用它们。例如，如果你正在编写一个API，在API用户调用的任何方法中，都不应该使用断言来检查参数是否为空。但是它可以在一个私有方法中使用，而不是作为API的一部分公开，以断言您的代码永远不会在不应该传递null参数时传递null参数。
当我不确定时，我通常更喜欢异常而不是断言。
其他回答
根据设计标准，你应该
坚持每一个假设。平均每五行就有一个断言。
using System.Diagnostics;
object GetObject()
{...}
object someObject = GetObject();
Debug.Assert(someObject != null);
作为一个免责声明，我应该提到我还没有发现实现这个IRL是实际的。但这是他们的标准。
仅在希望为发布版本删除检查的情况下使用断言。请记住，如果不在调试模式下编译，断言将不会触发。
对于检查为空的示例，如果这是在仅限内部的API中，我可能会使用断言。如果它在一个公共API中，我肯定会使用显式检查和抛出。
所有的断言应该是代码，可以优化为:
Debug.Assert(true);
因为它检验的是你已经假设为真的东西。例如:
public static void ConsumeEnumeration<T>(this IEnumerable<T> source)
{
if(source != null)
using(var en = source.GetEnumerator())
RunThroughEnumerator(en);
}
public static T GetFirstAndConsume<T>(this IEnumerable<T> source)
{
if(source == null)
throw new ArgumentNullException("source");
using(var en = source.GetEnumerator())
{
if(!en.MoveNext())
throw new InvalidOperationException("Empty sequence");
T ret = en.Current;
RunThroughEnumerator(en);
return ret;
}
}
private static void RunThroughEnumerator<T>(IEnumerator<T> en)
{
Debug.Assert(en != null);
while(en.MoveNext());
}
在上面，有三种不同的空参数方法。第一个接受它为允许的(它只是什么都不做)。第二个则抛出异常供调用代码处理(或不处理，导致错误消息)。第三种假设它不可能发生，并断言它是这样的。
在第一种情况下，没有问题。
在第二种情况下，调用代码有一个问题——它不应该用null调用GetFirstAndConsume，所以它会返回一个异常。
在第三种情况下，这段代码有一个问题，因为在调用它之前，它应该已经检查过en != null，所以它不是真的是一个错误。或者换句话说，它应该是理论上可以优化为Debug.Assert(true)的代码，sicne en != null应该始终为真!
将Debug.Assert()放在代码中任何需要进行完整性检查以确保不变量的地方。当编译Release版本时(即没有DEBUG编译器常量)，对DEBUG . assert()的调用将被删除，因此它们不会影响性能。
在调用Debug.Assert()之前仍然应该抛出异常。断言只是确保在开发过程中一切都如预期的那样。
您应该始终使用第二种方法(抛出异常)。
同样，如果你是在生产环境中(并且有一个发布版本)，抛出一个异常(在最坏的情况下让应用程序崩溃)比处理无效值和可能破坏客户数据(这可能要花费数千美元)要好。
