C# - Assert()方法有什么作用？它还有用吗？

Question

C# - Assert()方法有什么作用？它还有用吗？

Pok*_*kus 151 c# assert

我正在调试断点,我意识到断言调用？我以为它只适用于单元测试.它比断点更有用吗？既然我可以断点,我为什么要使用断言？

Answer 1

Pat*_*ins 192

在调试编译中,Assert将布尔条件作为参数,如果条件为false,则显示错误对话框.如果条件为真,程序将继续进行而不会中断.

如果你在Release中编译,那么所有Debug.Assert的都会被自动省略.

断言不是救生艇,它们是冰山探测系统.由于用户没有操纵船只,因此释放代码中的断言只是告诉他们他们注定要失败; 它不会让他们避开冰山. (107认同)
国际海事组织,从发布代码中省略断言就像在停靠时进行救生艇演习,然后在航行时将救生艇留在后面.:) (25认同)
Trace.Assert for release mode显然是参考:http://msdn.microsoft.com/en-us/library/system.diagnostics.trace.assert.aspx http://msdn.microsoft.com/en-us/library/ e63efys0.aspx (15认同)
如何在Release模式下获得Debug.Assert的相同行为？ (12认同)
@HamishGrubijan你为什么要在发布模式下使用`Debug.Assert`？ (8认同)
关于何时使用其中一个,请参阅[此答案](http://stackoverflow.com/a/5031211/533837) - 我同意这一点.简而言之,断言主要是测试_your自己的假设_,在_your自己的代码中进行,包括但不限于私有函数调用,以找到你在代码中出错的地方_.例外情况是任何人都可以调用的方法中的假设,例如,由第三方提供的代码调用的公共方法,或者当某些事情出错时_无论假设是否正确(例如网络错误). (7认同)
但是在你知道问题的时候早点失败似乎更好; 不那么混乱.但在那种情况下,我猜测抛出错误或使用代码合同会更好.Trace.Assert也适用于生产代码,但确实使用包含友好消息的重载,并注意用户可以忽略错误. (5认同)
我喜欢将'Assert`视为对类固醇的评论.1)将您的假设传达给未来的程序员(包括您自己)是一种简洁的方式; 2)它对Release没有性能影响; 3)与传统评论相比,它变得陈旧的可能性要小得多. (4认同)
发布中的断言基本上是检查后置条件是否有效的更简洁的方法。它遵循快速失败约定，以确保生成的异常尽可能靠近问题发生的位置，从而更容易识别问题的根源。 (2认同)

Answer 2

jua*_*uan 93

从代码完成

8防御性编程

8.2断言

断言是在开发期间使用的代码 - 通常是例程或宏 - 允许程序在运行时检查自身.当断言为真时,这意味着一切都按预期运行.当它为假时,这意味着它已在代码中检测到意外错误.例如,如果系统假定客户信息文件永远不会有超过50,000条记录,则程序可能包含一条断言,即记录数量小于或等于50,000.只要记录数小于或等于50,000,断言就会保持沉默.但是,如果它遇到超过50,000条记录,它将大声"断言"程序中存在错误.

断言在大型复杂程序和高可靠性程序中特别有用.它们使程序员能够更快地清除不匹配的接口假设,修改代码时出现的错误,等等.

断言通常需要两个参数:一个布尔表达式,用于描述假定应该为true的假设,以及一个要显示的消息(如果不是).

(......)

通常,您不希望用户在生产代码中看到断言消息; 断言主要用于开发和维护期间.断言通常在开发时编译到代码中,并从代码中编译生产.在开发过程中,断言会清除相互矛盾的假设,意外情况,传递给例程的错误值等等.在生产过程中,它们是从代码中编译出来的,因此断言不会降低系统性能.

《Writing Solid Code》一书也对断言的用法进行了很好的讨论。它们是一个很棒的调试工具！ (2认同)

Answer 3

the*_*sdj 38

当你不想断断每一小段代码来检查变量时,你应该使用它,但是如果存在某些情况你确实希望获得某种反馈,例如:

Debug.Assert(someObject != null, "someObject is null! this could totally be a bug!");

Run Code Online (Sandbox Code Playgroud)

@JoshDesmond`System.Diagnostics` (3认同)

Answer 4

Joe*_*Joe 14

断言还为您提供了另一个机会,可以轻松地嘲笑微软的UI设计技巧.我的意思是:一个带有三个按钮的对话框Abort,Retry,Ignore,以及如何在标题栏中解释它们的说明!

中止/重试/忽略是经典的!它是否曾经导致Windows 3.1一直显示这个断言？ (3认同)
@Joe这是应该只有开发人员才能看到的东西,而不是最终用户,所以更新它可能是一个极低优先级的项目.如果烦恼,可以修改Debug.Listeners或Trace.Listeners集合,将默认处理程序替换为任何您想要的处理程序. (3认同)
好吧，现在是2019年，相同的对话框/按钮仍在这里！ (2认同)

Answer 5

Jef*_*tes 10

Assert允许您断言条件(post或pre)适用于您的代码.这是记录您的意图的一种方式,如果您的意图不符合,调试器会通过对话通知您.

与断点不同,Assert与您的代码一起使用,可用于添加有关您的意图的其他详细信息.

Answer 6

Rya*_*yan 10

断言可以帮助您在测试和发布之间提供单独的消息传递行为.例如,

Debug.Assert(x > 2)

如果您正在运行"调试"构建而不是发布版本,则只会触发中断.这个行为有一个完整的例子在这里

Answer 7

Ser*_*nko 8

首先,Assert()方法可用于Trace和Debug类.
Debug.Assert()仅在调试模式下执行.
Trace.Assert()正在调试和发布模式下执行.

这是一个例子:

        int i = 1 + 3;
        // Debug.Assert method in Debug mode fails, since i == 4
        Debug.Assert(i == 3);
        Debug.WriteLine(i == 3, "i is equal to 3");

        // Trace.Assert method in Release mode is not failing.
        Trace.Assert(i == 4);
        Trace.WriteLine(i == 4, "i is equla to 4");

        Console.WriteLine("Press a key to continue...");
        Console.ReadLine();

Run Code Online (Sandbox Code Playgroud)

在调试模式下运行此代码,然后在发布模式下运行.

您会注意到在调试模式下,您的代码Debug.Assert语句失败,您将看到一个消息框,显示应用程序的当前堆栈跟踪.由于Trace.Assert()条件为真,因此在发布模式下不会发生这种情况(i == 4).

WriteLine() 方法只是为您提供了将信息记录到Visual Studio输出的选项.

Answer 8

小智 5

断言在契约设计 (DbC) 中占有重要地位，据我所知，它是由 Meyer, Bertand 引入/认可的。1997. 面向对象的软件构造。

一个重要的特性是它们不能产生副作用，例如您可以使用 if 语句处理异常或采取不同的行动方案（防御性编程）。

断言用于检查合同的前/后条件、客户/供应商关系 - 客户必须确保满足供应商的先决条件，例如。发送 5 英镑，供应商必须确保满足后置条件，例如。送出 12 朵玫瑰。（只是对客户/供应商的简单解释 - 可以接受更少并提供更多，但关于断言）。C# 还引入了 Trace.Assert()，可用于发布代码。

要回答这个问题，是的，它们仍然有用，但会增加代码的复杂性+可读性和时间+难以维护。我们还应该使用它们吗？是的，我们都会使用它们吗？可能不会，或者不会达到迈耶描述的程度。

（即使是我学习这项技术的 OU Java 课程也只展示了简单的示例，其余代码并未对大多数代码强制执行 DbC 断言规则，而是假定用于确保程序正确性！）

归档时间：	16 年，11 月前
查看次数：	146767 次
最近记录：	6 年，5 月前