[Mono-bugs] [Bug 71947][Wis] Changed - Debug.Assert not working out of the box
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 email@example.com.
--- 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 firstname.lastname@example.org 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...