Debug.WriteLine()具有以下签名的重载:
public static void WriteLine(string format, params Object[] args)
Trace.WriteLine()没有那么重载(虽然它拥有Debug.WriteLine()
所拥有的所有其他内容。
有谁知道这个遗漏的原因?
我认为没有理由让自己避开它? (我只是问,因为我正在实现一个日志记录界面,默认实现只会使用Debug.WriteLine()
和Trace.WriteLine()
,我想知道任何奇怪的后果。我无法想象。 )
答案 0 :(得分:3)
嗯,我不确定我说的是什么,但我抓住了机会。
当我反编译这些方法时,它们都使用相同的TraceInternal.WriteLine(string)
方法。
当我反编译Debug.WriteLine Method (String, Object[])
时;
public static void WriteLine(string format, params object[] args)
{
TraceInternal.WriteLine(string.Format((IFormatProvider) CultureInfo.InvariantCulture, format, args));
}
当我反编译Trace.WriteLine(string)
;
public static void WriteLine(string message)
{
TraceInternal.WriteLine(message);
}
正如您所看到的,唯一不同的是,第一个使用string.format()
方法。看起来对我来说没什么大不了的。
但遗漏的原因?我不知道。作为ken2k mentioned,我相信这只能由基类库开发人员完全回答..
答案 1 :(得分:3)
我发现了为什么我不应该在自己的代码中添加这样的接口的原因:因为它具有误导性。
乍一看,我以为 Debug.WriteLine("Value = {0}", "Test");
会打印:
Value = Test
但事实上它打印:
Test: Value = {0}
这是如此误导的原因是因为有很多类似的方法可以进行格式化,例如string.Format()
,Console.WriteLine()
等等。
所以,真的,应该避免这种误导性的功能,恕我直言。
这并没有直接回答我原来的问题 - 但它解释了为什么这个方法最初不在.Net中。它没有解释为什么他们在以后的版本中添加它。我现在认为他们不应该这样做。
(我现在通过复制NLog所做的事情来规避代码中的问题 - 我要求将类名传递给我的日志类的构造函数,以便类名永远不会传递给我的日志类的构造函数任何消息格式化程序。)