[Mono-bugs] [Bug 71947][Wis] Changed - Debug.Assert not working out of the box

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Mon, 31 Jan 2005 12:21:06 -0500 (EST)


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by jonpryor@vt.edu.

http://bugzilla.ximian.com/show_bug.cgi?id=71947

--- shadow/71947	2005-01-31 09:25:31.000000000 -0500
+++ shadow/71947.tmp.356	2005-01-31 12:21:06.000000000 -0500
@@ -100,6 +100,38 @@
 PS: About GUI libraries, if I'd be the one implmenenting the stuff
 then I'd just use the console by default. The gui libraries like gtk#
 and winforms should be responsible to register their own listener in
 their init functions.
 That would keep dependencies for main mono down. And give the user a
 dialogbox matching the gui library the rest of the application is using.
+
+------- Additional Comments From jonpryor@vt.edu  2005-01-31 12:21 -------
+The default behavior of the DefaultTraceListener shouldn't be changed.
+ That is, normal use via Write and WriteLine shouldn't generate
+console output.  Why?  Because it prevents use of the
+DefaultTraceListener when writing shell utilities which make use of
+standard input and standard output, as it adds random garbage.
+
+Further, one of the main ideas behind the TraceListener infrastructure
+is that you can leave it enabled in production (shipping) builds. 
+This allows you to not display extraneous output in normal operation,
+but if a problem comes up you can enable the listener in the
+application .config file, collect the output, and "debug" remotely. 
+If the DefaultTraceListener always writes to the console, the net
+effect will be that people will remove it from production builds,
+limiting its usefulness.
+
+However, that doesn't mean that it should always be silent.  I see an
+argument that DefaultTraceListener.Fail should always write messages
+to stderr.  I don't have a problem against this.  It does raise a
+question regarding whether stderr should be exclusive or inclusive of
+MONO_TRACE.  (That is, if MONO_TRACE is set, should stderr be written
+to _as_well_ in DefaultTraceListener.Fail?)
+
+As for aborting the process, we could add support for another
+environment variable, say MONO_DIE_ON_ASSERT_FAIL, and if this is set
+and DefaultTraceListener.Fail is invoked Environment.Exit will be
+invoked.  I'm not keen about that name, but I'm open to suggestions...
+
+PS. Thank you for the suggestion to support multiple GUIs.  This
+should greatly simplify implementing such a dialog while limiting
+mono's dependencies.  Guess I should implement that...