伪调试字符串的存在如何导致功能上的差异? [英] How could the existence of pseudo debug strings cause a difference in functionality?

问题描述

如果我在我的代码中撒满了这些东西:

If I have these sprinkled throughout my code:

MessageBox.Show("See a format exception yet? #1");//todo: remove

(其中有7个，从1..7开始编号，大多数显示(1,2,5,6,7))

(there are 7 of these, numbered from 1..7, most of which display (1,2,5,6,7))

我最后得到一个错误消息("异常:找不到表0位置:frmFunction.SetPlatypus ")

I end up with one err msg ("Exception: Cannot find table 0 Location: frmFunction.SetPlatypus")

如果我将所有这些注释掉，则会得到一个不同的err msg("异常:FormatException位置frmFunction.getDuckbillRecord ")

If I comment out all of those, I end up with a different err msg ("Exception: FormatException Location frmFunction.getDuckbillRecord")

怎么可能?这样的信息msg的存在/显示不应该对代码的执行方式/所采用的路径等没有影响吗?

How could this be? Shouldn't the existence/display of such an information msg have no effect on the way the code executes/the path it takes, etc.?

注意:getDuckbillRecord()是所有MessageBox的位置.

Note: getDuckbillRecord() is where all of the MessageBoxes are.

以RT的建议为动力，我想到了这一点:

Using RT's suggestions as motivation, I came up with this:

public static StringBuilder LogMsgs = new StringBuilder();

    public static void ExceptionHandler(Exception ex, string location)
    {
        try
        {
            LogMsgs.Append(string.Format("{0}\r\n", ex.Message)); //TODO: Comment out before deploying?
            DateTime dt = DateTime.Now;
            string timeAsStr = string.Format("{0}_{1}_{2}_{3}.txt", dt.Hour, dt.Minute, dt.Second, dt.Millisecond);
            using (StreamWriter file = new StreamWriter(timeAsStr))
            {
                file.WriteLine(LogMsgs.ToString());
            }
            . . .

//in the problematic code, replacing the MessageBox.Show() calls:

    TTBT.LogMsgs.Append("Made it to location 1 in frmOverFunction.GetDuckbillRecord()\r\n");

...而且确实有帮助-在7个代码路标"中的第一个之后立即到达了异常，因此该特定丹麦显然有些腐烂.

...and it did help - the exception is reached right after the first of 7 "code waypoints," so there's something rotten in that particular Denmark, apparently.

在能够在不崩溃的情况下运行应用程序的罕见经验之后，我意识到我还需要在主窗体的OnClosing()事件中写入文件的代码-在全局异常处理程序中已经工作了一段时间-我当时我猜想不会再次终止该应用程序.

After the rare experience of being able to run the app without crashing somewhere, I realized I also need that file-writing code in the main form's OnClosing() event - being in the global exception handler had worked for awhile - I wasn't expecting a clean termination of the app to ever occur again, I guess.

推荐答案

我强烈建议您不要使用MessageBox.Show(...)记录/跟踪/调试错误，因为会弹出一个对话框可能会引入许多细微的错误以及行为，重点等方面的变化，尤其是在您的UI流程/状态很重要的情况下.

I'd strongly encourage you NOT to use MessageBox.Show(...) to log/trace/debug errors, because popping-up a dialog can introduce many subtle bugs and changes in behavior, focus, etc., especially if your UI flow/state is important.

相反，使用System.Diagnostics.Trace编写跟踪代码(可以选择将其编译为生产/发行代码)，或者使用System.Diagnostics.Debug编写调试消息，这些消息在构建发行版本时将被删除.

Instead, use System.Diagnostics.Trace for writing tracing code (which you can optionally compile into your production/release code) or System.Diagnostics.Debug to write debug messages which get removed when you build your release version.

例如:

public void DoSomething(int a, int b)
{
    Trace.TraceInformation("Starting to do something: a = {0}, b = {1}",
        a, b);

    try 
    {
        int c = a / b;
    }
    catch (DivideByZeroException e)
    {
        Debug.WriteLine("OH NO ... 'b' WAS ZERO!!!! RUN AWAY!!!!");
        throw e;
    }

    Trace.TraceInformation("Done doing something");
}

在上面的示例中，调试输出将在调试版本中可用，但将在发行版本中删除.跟踪输出将在调试和零售错误中可用(除非您关闭TRACE构建参数)，但不会引入可衡量的性能影响，除非您连接了侦听器并开始将跟踪输出写入慢速介质(如旋转磁盘，自动收录机打印机)等；)

In the example above, the debug output will be available in debug builds, but will be removed in release builds. Trace output will be available in debug and retail bugs (unless you turn off the TRACE build parameter) but introduces no measurable perf impact unless you hook-up a listener and start writing trace output to a slow medium like spinning disks, ticker-tape printers, etc. ;)

在Visual Studio中使用Trace运行代码和/或使用Debug消息进行Debug构建时，这些消息将写入输出"窗格，因此您可以观察应用程序运行时的内部情况.

When you run code with Trace and/or Debug builds with Debug messages in Visual Studio, the messages are written to the Output pane so you can watch what's going on inside your app as it runs.

如果需要，还可以编写一个独立的跟踪侦听器，以侦听跟踪和/或调试消息，并将它们记录到文件/数据库中，或在控制台窗口(或GUI，如果要获取它们中显示)中显示它们花哨的).

If you want to, you can also write a stand-alone trace listener that listens for Trace and/or Debug messages and log them to a file/database or display them in a console window (or GUI if you want to get fancy).

您还可以使用 log4net 之类的工具，该工具使您可以将日志/跟踪消息写入各种文件格式，数据库等.

You can also use tools like log4net which enables you to write log/trace messages to a variety of file formats, databases, etc.

这篇关于伪调试字符串的存在如何导致功能上的差异?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！