Использование класса StackTrace в производственной среде для получения информации о вызывающем методе

Question

У нас есть класс "log", который использует Relection.MethodBase для отправки информации о текущем классе в журнал.

Вещи отражения. MetodBase происходят в самом классе.

Однако яхотелось бы переместить этот материал в один внешний класс синглтонного типа "log".

В этом сценарии внешний класс журнала должен получить информацию о CALLING, а не информацию о текущем методе.Для этого я использую stacktrace, которого нет в пространстве имен Reflection.

Могу ли я гарантировать, что «эта» конкретная информация (вызывающий метод) будет присутствовать в производственной среде?

 var stackTrace = new StackTrace();
 return LogManager.GetLogger(stackTrace.GetFrame(1).GetMethod().DeclaringType);

ура!

Answer 1

Да, даже в сборке "release" без каких-либо PDB вы будете иметь имена методов в трассировке стека. Но лично я считаю это запахом кода . Это подразумевает очень хрупкий путь кода (например, что произойдет, если вы создадите метод WriteLine, который вызывает метод Write, смотрите ли вы на вызывающую сторону в этом случае?). Также, вероятно, не дешево делать снимок трассировки стека при каждом вызове журнала.

Я недавно опубликовал вопрос об использовании MEF для добавления регистратора в мой класс, и я хотел также связать имя типа с данными журнала. MEF отлично сработал для меня, так как я смог импортировать экземпляр ILogger для каждого класса, который хотел его использовать, и когда экземпляр ILogger был импортирован, я установил для его свойства Category имя текущего класса. Нет отражения, нет стека следов. Это сработало очень хорошо для меня.

Answer 2

Джош имеет право. Взятие следов стека очень дорого, и его следует избегать. Трудно понять, что именно ты делаешь, но это звучит довольно плохо. Моим первым предложением было бы еще раз взглянуть на вашу производственную среду и посмотреть, какие службы ведения журналов уже существуют и как вы можете их использовать.

Если вы не можете, то я хотел бы изучить уже имеющиеся API, такие как Log4j, SLF4j и Commons, чтобы увидеть, как вы могли бы их использовать. Наконец, если вы все еще не можете его использовать, вы можете, по крайней мере, взглянуть на их источник, чтобы увидеть, как они работают. Также источник для JUnit выполняет анализ трассировки стека, если я правильно помню, так что есть еще один источник идей.

Но мое последнее слово было бы, чтобы все было как можно проще. Не ходите вокруг, создавая следы стека. Вообще говоря, вы действительно беспокоитесь о них только тогда, когда возникает исключение, а затем оно передается вам. Вам не нужно ничего делать, кроме как передать это.