我应该使用 .net 中的 Debug 类吗？
我读了很多关于 调试类 最近。
我个人对此很纠结。 我可以看到它改进了创建非常棘手的算法的过程。 但它也向我的应用程序添加了很多代码，我必须费力地完成这些不必要的代码。 拥有调试器应该消除对样板代码的需要，无论它是否被自动删除以用于发布版本，对吗？
我还对那些充分利用 Debug 类的人是如何做到这一点感兴趣的。 您是否编写了 Debug.Assert 语句，还是 同意 Ed Kaim 的观点，您应该使用 Debug.WriteLine 和 Debug.Fail。
I've been reading a lot about the Debug class lately.
I'm pretty torn about it personally. I can see it improving the process of creating really tricky algorithms. But it also adds a lot of code to my app that I have to wade through unnecessarily. Having a Debugger should remove the need for boiler plate code, whether it is stripped out for a release build automatically or not right?
I am also interested in how those of you that do put the Debug class to good use are doing it. Do you write Debug.Assert statements at all, or do you agree with Ed Kaim that Debug.WriteLine and Debug.Fail are all you should use.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我个人同意埃德·凯姆的观点。 就我个人而言，我觉得良好的测试实践已经取代了我所有工作中的 Debug.Assert 调用。 此外，我也几乎放弃了 Debug.Fail 的使用 - 任何时候我想使用它，我几乎发现我想在发布和调试中抛出异常，所以我通常不会看到重点。
话虽这么说，我仍然使用一些调试打印语句来增强我的调试（通过 Debug.WriteLine），特别是在数字代码中......我承认这是对老式 printf 调试的回归，但通常情况下，这仍然是追踪问题的最快方法，尤其是那些没有出现在调试器中的问题（由于计时问题、线程等）。
I personally agree with Ed Kaim. Personally, I feel like good testing practices have replaced Debug.Assert calls in all of my work. In addition, I have pretty much abandoned my use of Debug.Fail as well - any time I want to use this, I pretty much find that I want to throw an exception in release as well as debug, so I don't typically see the point.
That being said, I do still use some of the debug printing statements to augment my debugging (via Debug.WriteLine), especially in numerical code... I acknowledge that it's a throwback to old-school printf debugging, but often, that's still the fastest way to track down a problem, especially one that doesn't show up in the debugger (due to timing issues, threading, etc).
就我个人而言，我很少在任何编程中使用 Debug 类。 我读过很多评论和建议，例如 John Robbins（ 的作者）的评论和建议调试 .NET 2.0 应用程序 和 Bugslayer 列）关于为什么你应该主动断言 - 特别是方法的参数。
我遇到的问题是这样的 - 假设我要编写这样的代码：
这在使用调试构建的开发过程中效果很好，但无论如何我最终都会这样做：
如果“源”有可能什么都没有，那么我就去无论如何都要对其进行“如果”检查。 我不会在发布版本中保留断言调用。
我不使用 Debug 类的另一个原因是我编写了大量单元测试。 这样做使我覆盖了很多代码路径，因此不需要在我的代码中包含 Debug.Assert。
至于调试日志记录，我只需使用 Trace 调用和 SysInternals DebugView或文本文件来记录跟踪调用的输出。
我很想听听其他人关于这个主题的意见，因为我也有兴趣了解他们在开发过程中如何使用 Debug 类。 这是一个我没有太多经验的领域，所以我渴望学习。
Personally, I rarely use the Debug class at all for any of my programming. I've read a lot of comments and suggestions, such as those by John Robbins (author of Debugging .NET 2.0 Applications and the Bugslayer columns) about why you should be asserting proactively - especially parameters for methods.
The problem I have is this - say I was to write code like this:
This works well during development with debug builds, but I end up doing this anyway:
If there's a chance for 'source' to be nothing, then I'm going to do an 'If' check on it anyway. I'm not going to leave the assert call in the release build.
The other reason I don't use the Debug class is that I write a lot of unit tests. Doing so has led me to covering a lot of code paths, thus having a Debug.Assert in my code is not required.
As for debug logging, then I simply use Trace calls and SysInternals DebugView or text files to log the output of trace calls.
I would love to hear from others on this topic, since I'm also interested in knowing how they might be using the Debug class during development. It's an area I don't have much experience in, so I'm eager to learn.
与简单地在调试器中运行代码相比，使用 Debug 类的主要优点是您可以获得一个日志文件（使用 Debug.Writeline 语句），您可以与同事共享该日志文件/存储您的记录。
与编写单独的测试方法相比，Debug.Assert 的优点是紧凑，并且检查恰好位于所需的位置，而不是单独的方法。
The main advantage of using the Debug class over simply running code in you debugger is that you get a log file (using Debug.Writeline statements), which you can share with colleagues/store for your records.
The advantages that Debug.Assert has over writing a separate test method are compactness, and the fact that the check is in exactly the place it needs to be, rather than a separate method.
我自己的观点是，Debug.Assert 和 Debug.Fail 经常被滥用来向最终用户“隐藏”错误。 如果有必要，我宁愿写入错误日志或引发异常。
My own opinion is that Debug.Assert and Debug.Fail are often misused to "hide" errors from end-users. I'd rather write to an error log or throw an exception if warranted.
我不能告诉你是否应该使用它，但我可以建议我使用它的时间。
当我想要有关函数/变量/过程/结果的更多信息时，我使用调试，但我知道一旦发布该信息就不再相关。 例如，我使用 Debug.Writeline 来验证进程的正确时间顺序，或使用 Debug.Assert 来验证值是否正确。
我认为 Kaim 只是说很容易滥用 Debug.Assert。 不要使用 Debug.Assert 来捕获生产中可能发生的问题。 Debug.Assert 用于开发过程中的简单检查，例如提醒标志。 它并不意味着处理发布代码错误。 您可以每隔一行放置一个 Debug.Assert ，而不必担心它会减慢发布代码的速度。
I can't tell you if you should, but I can suggest times when I use it.
I use Debug when I want more information about a function/variable/process/result but I know once it's released that info is no longer relevant. I use Debug.Writeline to verify correct chronology of a process, for example, or Debug.Assert to verify a value is what it should be.
I think Kaim is just saying it's easy to misuse Debug.Assert. Don't use Debug.Assert to catch issues that could occur in production. Debug.Assert is meant for simple checks during development, like a reminder flag. It is not meant to handle release-code errors. You can put a Debug.Assert every other line without worrying it is slowing down the release code.
我建议根本不要使用 Debug 类； 我不。 一般来说，我发现对于开发来说，调试器足以满足我的所有需求； 我会记录我真正需要跟踪的内容。 关于日志记录最关键的部分是日志记录也发生在生产代码中，这绝对重要。 根据定义，
Debug仅在调试代码中起作用； 虽然它可能有助于帮助您在开发过程中查找某些内容，但如果查找的内容如此重要，请将其记录下来。 严重地。 如果它很重要并且很棘手，以至于您需要特殊的工具才能找到它，请记录下来； 它可能会作为边缘情况出现在您的生产环境中，那么您会做什么？就其价值而言，我发现 log4net 对于日志记录而言非常有用且强大。 我建议任何时候都使用它，而不是使用
Debug类。I would suggest not to use the
Debugclass at all; I don't. Generally, I find for development that the debugger is good enough for all of my needs; and what I really need to track, I log. The most critical part about logging is that the logging also occurs in production code, which can be absolutely important.Debugby definition is only functional in debug code; while it might be useful for helping you find something during development, if it's that important to find, log it. Seriously. If it's important to find and tricky enough that you need a special facility to get to it, log it; it's likely to show up in your production environment as an edge case, and what will you do then?And for what it's worth, I find log4net to be incredibly useful and robust for logging purposes. I'd recommend its use over the use of the
Debugclass any day.我们经常使用 Debug.Assert - 对于您所做的每一个重要假设，拥有一个 Assert 并没有什么害处。
相当有用但很老的文章 - IDesign C# 编码标准 此处
We use Debug.Assert very often - for every important assumption that you would make it does not harm to have an Assert.
Quite a useful but old article - IDesign C# Coding Standards here
合约的 Debug.Assert 测试。 它有一个小好处，那就是它不存在于发布代码中。 if + 抛出异常的情况并非如此。
我使用 Debug.WriteLine 来处理 UI 事件，因为调试器会妨碍（例如，从 VS 窗口切换到应用程序窗口时会再次调用刷新事件）。
Debug.Assert test for contract. It has a little benefit that it is not present in release code. That is not the case with if + throwing exception case.
I use Debug.WriteLine for UI events because there debugger gets in the way (e.g refresh events are called again when switching from VS window to app window).