4

I have a Console Application which reads some data, fills it into a Dictionary-like structure, manipulates it and then makes some output files.

However, when printing output it sometimes prints:

Fail:

Where it really shouldn't. I cannot find anything on Google (not really much to search for) and I cannot find anything when I search for the string "fail" in my solution (so it's not my code doing it).

I have no idea why this is happening, the relevant block does often generate exceptions but I catch them, and when I was using Console.WriteLine instead of Trace.WriteLine it was working fine, although I cannot easily verify that this is the cause.

I have no idea how to fix this.

What could possibly cause Fail: being printed to the console?

How do I put a breakpoint to stop at it?

Where do I even start looking to figure this out?

Superbest
  • 25,318
  • 14
  • 62
  • 134
  • 2
    Vague as the question might be, I feel that I have a legitimate problem. If anyone has suggestions for what other info I could provide, be my guest. That said, silent down votes aren't very helpful - without being told what's wrong all I can conclude is that the voter was just in a cross mood. – Superbest Nov 20 '12 at 11:29
  • 2
    May it be the trace output for a failed assertion? – Adriano Repetti Nov 20 '12 at 11:39
  • @Adriano yes, turns out that's the case. There was an Assert in there that didn't had no failure message. Can you post that as an answer so I can accept it? – Superbest Nov 20 '12 at 11:45
  • +1 question is legitimate, @Superbest - maybe adding some code or at least telling us which classes you use (StreamReader/Dictionary) etc. may help point us in the right direction – Blachshma Nov 20 '12 at 11:47
  • @Superbest Don't mind, it was just a guess without any help to find where the problem was...too little to be an answer. Just delete the question or post your own answer with a more detailed explanation. – Adriano Repetti Nov 20 '12 at 11:49

1 Answers1

2

Thanks to Adriano's adroit hunch, I was able to suspect assertions as the culprit.

Indeed, the code block that was running when the mysterious Fail: messages were printed did call an assertion like this:

Debug.Assert(myString.Length > 0);

Clearly, "Fail:" is meant to be understood as "Assertion fail". I could verify this by changing it to:

Debug.Assert(myString.Length > 0, "Assertion failed with myString == \"" + myString + "\".");

This changed the Fail: messages to Fail: Assertion failed with myString == "" and dispelled the confusion, and gave me a handle on the problem for further debugging (since I know the assertion is the exact line generating the fail messages).

It turns out that in debug mode, Visual Studio does not break on assert failure but instead simply prints the failure message to the output (enabling breaks is discussed here). In my case, I had been using a trace listener so that my program's output would be printed to a file as well as the console. To do this, I used the following initialization code:

    private static void PrepareListeners()
    {
        Trace.Listeners.Clear();

        var logPath = "/path/to/my/file.txt";
        File.Delete(logPath);
        var textListener = new TextWriterTraceListener(logPath);

        var consoleListener = new ConsoleTraceListener(false);
        consoleListener.TraceOutputOptions = TraceOptions.DateTime;

        Trace.Listeners.Add(textListener);
        Trace.Listeners.Add(consoleListener);
        Trace.AutoFlush = true;
    }

And afterwards I had been producing output with Trace.WriteLine. It would appears that the trace listeners are picking up the assertion failure messages, too. (They show up in my log file as well as the console.)

Community
  • 1
  • 1
Superbest
  • 25,318
  • 14
  • 62
  • 134