到目前为止，我已经做了一年的专业软件工程师，并获得了计算机科学学位。我知道c++和C中的断言有一段时间了，但直到最近才知道它们存在于c#和。net中。
我们的生产代码不包含任何断言，我的问题是这个…
我应该开始在我们的生产代码中使用断言吗?如果可以，什么时候使用它最合适?这样做会更有意义吗
Debug.Assert(val != null, "message");
or
if ( val == null )
throw new exception("message");
当前回答
我不会在产品代码中使用它们。抛出异常，捕获和记录。
在asp.net中也需要小心，因为断言可以显示在控制台上并冻结请求。
其他回答
将Debug.Assert()放在代码中任何需要进行完整性检查以确保不变量的地方。当编译Release版本时(即没有DEBUG编译器常量)，对DEBUG . assert()的调用将被删除，因此它们不会影响性能。
在调用Debug.Assert()之前仍然应该抛出异常。断言只是确保在开发过程中一切都如预期的那样。
我不知道它在c#和。net中是怎样的，但在C中assert()只在使用- ddebug编译时工作-如果没有编译，最终用户将永远不会看到assert()。仅供开发人员使用。我经常使用它，它有时更容易跟踪错误。
使用断言检查开发人员的假设，使用异常检查环境的假设。
如果您希望在生产代码中使用断言(即发布构建)，您可以使用Trace。Assert而不是Debug.Assert。
这当然会增加生产可执行文件的开销。
此外，如果您的应用程序在用户界面模式下运行，则默认情况下将显示断言对话框，这可能会让您的用户感到不安。
您可以通过删除DefaultTraceListener来覆盖这种行为:查看Trace的文档。MSDN中的侦听器。
总之,
使用调试。自由断言，以帮助在调试版本中捕获错误。 如果你使用Trace。在用户界面模式下断言，您可能希望删除DefaultTraceListener以避免让用户感到不安。 如果你测试的条件是你的应用程序无法处理的，你可能最好抛出一个异常，以确保执行不会继续。请注意，用户可以选择忽略断言。
我不会在产品代码中使用它们。抛出异常，捕获和记录。
在asp.net中也需要小心，因为断言可以显示在控制台上并冻结请求。
