Debug.Assert() message so large it is cropped

[Zytan]

I am getting a Debug.Assert() firing which shows a mesasge so large
that it is cropped. But it crops off the beginning. So, I have no
idea what assertion is.

My code is not complex. It's just the main form invoking the c'tor of
a class, and this c'tor calls a static function that fires the
assertion. So, it's just Form1 -> Class C'tor -> Membe Function.

What can I do about this? Is Debug.Assert() really this useless?
There has to be a work around. I can't see this being a problem that
no one noticed. But, I also can't see this not being easily
reproducable on any workstation. Can I increase the message size?

thank for any help!!

Zytan

 

[Zytan]

So, I have no idea what assertion is.

...
Is Debug.Assert() really this useless?

This isn't true since, duh, if I clicked 'Retry'=Debug, I go straight
to the source code of the assertion!

But, I'd still like to know why the entire message doesn't show.

Zytan

 

[AvdP]

This isn't true since, duh, if I clicked 'Retry'=Debug, I go straight
to the source code of the assertion!

But, I'd still like to know why the entire message doesn't show.

Zytan

You can see the entire message in the output window too (VS - Ctrl+W, O).

Reagrds,
Anne

 

[Zytan]

You can see the entire message in the output window too (VS - Ctrl+W, O).

Yes and no. You can see the *same truncated* message in the Output
Window. You cannot see the entire message in the OutPut Window.

No, WAIT A SECOND, I'm wrong. I see this in the Output Window:

---- Assert Short Message ----

---- Assert Long Message ----


at LoginForm.btnTest_Click(Object sender, EventArgs e) C:\path\to
\the\source\file.cs(line_number)
....
....
etc.

Which is the same as in the message box. Is this how the assertion is
displayed? Where's the TEXT of the assertion from the code itself???

Oh right, c# has no macros, so the can't implement _assert like C
does. Damn.

I wish the message box didn't leave 3 or 4 empty lines implying that
there's something missing, and start the assertion with "at" implying
there's something missing.

Ok, this is something the compiler could do. It already removed all
Debug. calls, so why not add even more code to the Debug.Assert, and
pass in the TEXT of the assertion, so we know what the problem is?

Zytan

 

[AvdP]

Oh right, c# has no macros, so the can't implement _assert like C

does. Damn.

Instead of using the DefaultTraceListener you can write your own Listener
class (derived from TraceListener) to output the message to a file, eventlog
(e-mail, WWW, RSS, SMS or whatever way you want to get notified).

To give a clue, here is a basic sample using the StackTrace class (has to be
improved):

public class MyListener : TraceListener
{
public override void Write(string message){} // work this out
public override void WriteLine(string message){} // work this out

public override void Fail(string message)
{
HandleFail(message, string.Empty);
}

public override void Fail(string message, string detailMessage)
{
HandleFail(message, detailMessage);
}

private void HandleFail(string message, string detailMessage)
{
StackTrace st = new StackTrace(true);
Console.WriteLine("{0} {1}\r\n{2}", message, detailMessage, new
StackTrace(true).ToString());

}
}

public static void Main()
{
Trace.Listeners.Add(new MyListener());
Debug.Assert(false, "Oops"); // force assertion
Trace.Flush();
}

Regards,
Anne

 

[Zytan]

Instead of using the DefaultTraceListener you can write your own Listener

class (derived from TraceListener) to output the message to a file, eventlog
(e-mail, WWW, RSS, SMS or whatever way you want to get notified).

To give a clue, here is a basic sample using the StackTrace class (has to be
improved):

Wow, cool! I don't need anything like this for now, but thanks, Anne!

Zytan

 

[Zytan]

Instead of using the DefaultTraceListener you can write your own Listener

class (derived from TraceListener) to output the message to a file, eventlog
(e-mail, WWW, RSS, SMS or whatever way you want to get notified).

I better understand what you were saying now, from our most recent
thread. Although to be critical, I wouldn't need my own TraceListener
class to log to a file, as this article you gave me shows:
http://www.15seconds.com/issue/020910.htm

I am not sure why. Oh, because a TextWriterTraceListener already
exists (the class I would have made). But, yes, for something else,
other than writing to a file, I'd need to make my own.

To give a clue, here is a basic sample using the StackTrace class (has to be
improved):

public class MyListener : TraceListener
{
public override void Write(string message){} // work this out
public override void WriteLine(string message){} // work this out

public override void Fail(string message)
{
HandleFail(message, string.Empty);
}

public override void Fail(string message, string detailMessage)
{
HandleFail(message, detailMessage);
}

private void HandleFail(string message, string detailMessage)
{
StackTrace st = new StackTrace(true);
Console.WriteLine("{0} {1}\r\n{2}", message, detailMessage, new
StackTrace(true).ToString());

}

}

public static void Main()
{
Trace.Listeners.Add(new MyListener());
Debug.Assert(false, "Oops"); // force assertion
Trace.Flush();
}

Regards,
Anne

Thanks Anne, this is a great help!

Zytan

 

[AvdP]

thread. Although to be critical, I wouldn't need my own TraceListener

class to log to a file, as this article you gave me shows:
http://www.15seconds.com/issue/020910.htm

I am not sure why. Oh, because a TextWriterTraceListener already
exists (the class I would have made). But, yes, for something else,
other than writing to a file, I'd need to make my own.

TextWriterTraceListener writes only the string parameter(s) of Debug.Assert.
You wanted the entire stackdump, so I suggested to create your own
TraceListener.

Regards,
Anne

 

[Zytan]

TextWriterTraceListener writes only the string parameter(s) of Debug.Assert.

You wanted the entire stackdump, so I suggested to create your own
TraceListener.

Oh, right, that is very cool. I don't think the Debug.Assert messages
were being cropped, so it's ok. But, that's a neat feature to be able
to show the call stack.

Thanks, Anne

Zytan