到目前为止,我已经做了一年的专业软件工程师,并获得了计算机科学学位。我知道c++和C中的断言有一段时间了,但直到最近才知道它们存在于c#和。net中。
我们的生产代码不包含任何断言,我的问题是这个…
我应该开始在我们的生产代码中使用断言吗?如果可以,什么时候使用它最合适?这样做会更有意义吗
Debug.Assert(val != null, "message");
or
if ( val == null )
throw new exception("message");
到目前为止,我已经做了一年的专业软件工程师,并获得了计算机科学学位。我知道c++和C中的断言有一段时间了,但直到最近才知道它们存在于c#和。net中。
我们的生产代码不包含任何断言,我的问题是这个…
我应该开始在我们的生产代码中使用断言吗?如果可以,什么时候使用它最合适?这样做会更有意义吗
Debug.Assert(val != null, "message");
or
if ( val == null )
throw new exception("message");
当前回答
如果您希望在生产代码中使用断言(即发布构建),您可以使用Trace。Assert而不是Debug.Assert。
这当然会增加生产可执行文件的开销。
此外,如果您的应用程序在用户界面模式下运行,则默认情况下将显示断言对话框,这可能会让您的用户感到不安。
您可以通过删除DefaultTraceListener来覆盖这种行为:查看Trace的文档。MSDN中的侦听器。
总之,
使用调试。自由断言,以帮助在调试版本中捕获错误。 如果你使用Trace。在用户界面模式下断言,您可能希望删除DefaultTraceListener以避免让用户感到不安。 如果你测试的条件是你的应用程序无法处理的,你可能最好抛出一个异常,以确保执行不会继续。请注意,用户可以选择忽略断言。
其他回答
将Debug.Assert()放在代码中任何需要进行完整性检查以确保不变量的地方。当编译Release版本时(即没有DEBUG编译器常量),对DEBUG . assert()的调用将被删除,因此它们不会影响性能。
在调用Debug.Assert()之前仍然应该抛出异常。断言只是确保在开发过程中一切都如预期的那样。
我不知道它在c#和。net中是怎样的,但在C中assert()只在使用- ddebug编译时工作-如果没有编译,最终用户将永远不会看到assert()。仅供开发人员使用。我经常使用它,它有时更容易跟踪错误。
您应该始终使用第二种方法(抛出异常)。
同样,如果你是在生产环境中(并且有一个发布版本),抛出一个异常(在最坏的情况下让应用程序崩溃)比处理无效值和可能破坏客户数据(这可能要花费数千美元)要好。
您应该使用Debug。断言来测试程序中的逻辑错误。编译器只能通知您语法错误。因此,您肯定应该使用Assert语句来测试逻辑错误。比如测试一个销售汽车的项目,只有蓝色的宝马可以得到15%的折扣。编译器不能告诉你你的程序在执行这个操作时逻辑上是否正确,但是assert语句可以。
我已经在这里阅读了答案,我认为我应该添加一个重要的区别。使用断言有两种非常不同的方式。一种是作为临时的开发人员快捷方式,表示“这不应该真的发生,所以如果它发生了,就告诉我,这样我就可以决定怎么做”,有点像一个条件断点,用于你的程序能够继续的情况。另一种方法是在代码中假设有效的程序状态。
在第一种情况下,断言甚至不需要出现在最终代码中。您应该使用Debug。在开发期间断言,如果/当不再需要时,您可以删除它们。如果你想要保留它们或者忘记删除它们,没有问题,因为它们在发布汇编中不会有任何后果。
But in the second case, the assertions are part of the code. They, well, assert, that your assumptions are true, and also document them. In that case, you really want to leave them in the code. If the program is in an invalid state it should not be allowed to continue. If you couldn't afford the performance hit you wouldn't be using C#. On one hand it might be useful to be able to attach a debugger if it happens. On the other, you don't want the stack trace popping up on your users and perhaps more important you don't want them to be able to ignore it. Besides, if it's in a service it will always be ignored. Therefore in production the correct behavior would be to throw an Exception, and use the normal exception handling of your program, which might show the user a nice message and log the details.
跟踪。Assert有实现这一点的完美方法。它不会在生产环境中被删除,并且可以使用app.config配置不同的侦听器。 因此,对于开发来说,默认的处理程序就可以了,对于生产来说,您可以创建一个简单的TraceListener(如下所示),它会抛出一个异常并在生产配置文件中激活它。
using System.Diagnostics;
public class ExceptionTraceListener : DefaultTraceListener
{
[DebuggerStepThrough]
public override void Fail(string message, string detailMessage)
{
throw new AssertException(message);
}
}
public class AssertException : Exception
{
public AssertException(string message) : base(message) { }
}
在产品配置文件中:
<system.diagnostics>
<trace>
<listeners>
<remove name="Default"/>
<add name="ExceptionListener" type="Namespace.ExceptionTraceListener,AssemblyName"/>
</listeners>
</trace>
</system.diagnostics>