我什么时候应该使用 Debug.Assert()? [英] When should I use Debug.Assert()?

问题描述

我已经成为专业软件工程师大约一年了，毕业于 CS 学位.我早就知道 C++ 和 C 中的断言，但直到最近才知道它们存在于 C# 和 .NET 中.

I've been a professional software engineer for about a year now, having graduated with a CS degree. I've known about assertions for a while in C++ and C, but had no idea they existed in C# and .NET at all until recently.

我们的生产代码不包含任何断言，我的问题是...

Our production code contains no asserts whatsoever and my question is this...

我应该开始在我们的生产代码中使用断言吗?如果是这样，它什么时候使用最合适?这样做更有意义吗

Should I begin using Asserts in our production code? And if so, When is its use most appropriate? Would it make more sense to do

Debug.Assert(val != null);

或

if ( val == null )
    throw new exception();

推荐答案

在 调试 Microsoft .NET 2.0 应用程序 John Robbins 有很大一部分是关于断言的.他的主要观点是:

In Debugging Microsoft .NET 2.0 Applications John Robbins has a big section on assertions. His main points are:

1. 大胆断言.断言永远不会太多.
2. 断言不会取代异常.例外涵盖了您的代码要求的内容；断言涵盖了它假设的事情.
3. 一个写得很好的断言不仅可以告诉您发生了什么以及发生了什么(例如异常)，还可以告诉您原因.
4. 异常消息通常很神秘，需要您通过代码向后工作以重新创建导致错误的上下文.断言可以保留发生错误时程序的状态.
5. 断言兼作文档，告诉其他开发人员您的代码所依赖的隐含假设.
6. 当断言失败时出现的对话框让您可以将调试器附加到进程中，这样您就可以在堆栈周围进行检查，就像在那里放置了一个断点一样.

PS:如果您喜欢 Code Complete，我建议您继续阅读本书.我购买它是为了学习使用 WinDBG 和转储文件，但前半部分包含了帮助首先避免错误的技巧.

PS: If you liked Code Complete, I recommend following it up with this book. I bought it to learn about using WinDBG and dump files, but the first half is packed with tips to help avoid bugs in the first place.

这篇关于我什么时候应该使用 Debug.Assert()?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！