Используя Класс StackTrace в продуктивной среде для получения информации о вызывающем методе
У нас есть класс "журнала", который использует Переразночтение. MethodBase для отправки текущей информации о классе в журнал.
Отражение. Материал MethodBase происходит в самом классе.
Однако я хотел бы переместить тот материал в единственный внешний одноэлементный класс типа "журнала".
В этом сценарии внешний класс журнала должен получить информацию о ВЫЗОВЕ, не информацию о существующем методе. Я использую stacktrace, чтобы сделать это, которое не находится в Пространстве имен отражения.
Я могу гарантировать, что "та" определенная информация (вызывающий метод) будет там в продуктивной среде?
var stackTrace = new StackTrace();
return LogManager.GetLogger(stackTrace.GetFrame(1).GetMethod().DeclaringType);
удачи!
2 ответа
Да, даже в «выпускной» сборке без каких-либо PDB у вас будут имена методов в трассировке стека. Но лично я бы посчитал это запахом кода . Это подразумевает очень хрупкий путь кода (например, что произойдет, если вы создадите метод WriteLine, который вызывает метод Write, смотрите ли вы в этом случае на вызывающего абонента?). Также, вероятно, не дешево делать снимок трассировки стека при каждом вызове журнала.
Недавно я разместил вопрос об использовании MEF для внедрения регистратора в мой класс, и я также хотел связать имя типа с данными журнала. MEF сработал для меня очень хорошо, поскольку я смог импортировать экземпляр ILogger для каждого класса, который хотел его использовать, и когда экземпляр ILogger был импортирован, я бы установил его свойство Category на имя текущего класса. Нет отражения, нет трассировки стека. У меня это сработало очень хорошо.
Джош прав. Получение трассировок стека очень дорого, и этого следует избегать. Трудно понять, что именно вы делаете, но звучит довольно плохо. Сначала я предлагаю еще раз взглянуть на вашу производственную среду и посмотреть, какие службы ведения журналов уже существуют и как вы можете их использовать.
Если вы не можете, я бы посмотрел на уже доступные API, такие как Log4j, SLF4j и ведение журнала Commons, чтобы увидеть, как вы могли бы их использовать. Наконец, если все еще невозможно использовать, вы можете по крайней мере посмотреть на их источник, чтобы увидеть, как они работают. Также источник для JUnit выполняет анализ трассировки стека, если я правильно помню, так что есть еще один источник идей.
Но мое последнее слово было бы сделать все как можно проще. Не создавайте трассировки стека. Вообще говоря, вы действительно беспокоитесь о них только тогда, когда происходит исключение, а затем оно передается вам. Вам не нужно ничего делать, кроме как передать это.