Почему `Trace.Writeline()` отсутствует `WriteLine (строковый формат, params Object [] args)` overload?

Question

Debug.WriteLine() имеет перегрузку со следующей подписью:

public static void WriteLine(string format, params Object[] args)

Trace.WriteLine() не имеет, что перегрузка (хотя у него есть все остальные, которые Debug.WriteLine() имеет).

Кто-нибудь знает причину этого упущения?

У меня нет причин для того, чтобы избежать этого, полагаю? (Я только спрашиваю, потому что я реализует интерфейс протоколирования и реализация по умолчанию будет использовать только Debug.WriteLine() и Trace.WriteLine(), и я хочу, чтобы быть в курсе каких-либо странных последствий. Я не могу представить себе, хотя.)

Answer 1

Ну , Я не уверен, что я говорю, но я рискну.

Когда я декомпилировал эти методы, они оба используют один и тот же метод 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, я считаю, что на это можно ответить totaly только разработчиками библиотеки базового класса.

Answer 2

Я обнаружил причину, по которой я не должен добавлять такой интерфейс в свой собственный код: потому что он вводит в заблуждение.

На первый взгляд, я думал, что

Debug.WriteLine("Value = {0}", "Test");

напечатает:

Value = Test

Но на самом деле она печатает:

Test: Value = {0}

Причина, по которой это настолько вводит в заблуждение, состоит в том, что существует так много подобных методов, которые форматируют, например, такие как string.Format(), Console.WriteLine() и так далее.

Так что, такой вводящей в заблуждение функции следует избегать, ИМХО.

Это не отвечает на мой первоначальный вопрос напрямую - но это объясняет, почему метод не был первоначально в .Net. Он не объясняет, почему они добавили его в более позднюю версию. Я сейчас считаю, что их не должно было быть.

(Теперь я обошел проблему в своем коде, скопировав то, что делает NLog - мне нужно передать имя класса (с помощью фабричного метода) в конструктор моего класса ведения журнала, чтобы имя класса никогда не было передан в любой из форматов сообщений.)