1
Log ( MethodBase.GetCurrentMethod().DeclaringType.Name + MethodBase.GetCurrentMethod.Name + "blah blah..."  );

returns something like

MyClass.ThisMethod : Error is blah blah..

Now,

1) MethodBase.GetCurrentMethod().DeclaringType.Name is capable of throwing a NullReferenceException. How to avoid this? Or what is the good way to know the class in which the currentmethod is present ?

2) Is there any other way to achieve the same ?

now he who must not be named.
  • 9,166
  • 26
  • 81
  • 144
  • 1
    Wouldn't the Stack trace information present in the exception sufficient to show which method threw the error? If you need this for logging other kind of messages, then reflection **may** hurt the performance. – Ramesh Nov 20 '12 at 05:45
  • Yes, I think the stack trace info would be sufficient for development. But, from the customer perspective as soon as he gives us the log message, I think this detailed info would be great for quick debug from our side ? – now he who must not be named. Nov 20 '12 at 06:00
  • @Ramesh: reflection may hurt the performance ? – now he who must not be named. Nov 20 '12 at 06:00
  • Even from customer systems, you can write sophisticated logging systems which can pump the error details to a DB along with Stack trace and give them the ID to this record to the customer. When the customer sends this ID to you, you get the entire information without customer knowing your implementation details. Yes, frequent use of reflection would hurt the performance of the app. You should be ideally using reflection once and cache the result across your app. – Ramesh Nov 20 '12 at 06:10
  • Thanks @Ramesh: Will examine that. Is there any such sophisticated logging systems for dotnet that you recommend? – now he who must not be named. Nov 20 '12 at 06:28
  • log4net, Enterprise Logging Application block, ELMAH if you are using Web Apps... – Ramesh Nov 20 '12 at 08:07

2 Answers2

3

For error event logging, or even for application function or method completion logging, the performance of the reflection calls are usually not an issue. Especially since it would usually be preferable to use the reflection calls over having a named string in each class and method.

Calls to MethodBase should not be used in any performance critical sections. In those cases the reflection values should be cached prior to use if possible, or alternative objects used, such as the aforementioned named strings.

eg. Log (m_zClassName, zMethodName, "Method Wizbot completed.");

Benchmark

In benchmarks on my i7-2600k each call to MethodBase.GetCurrentMethod() is approximately 1600 nanoseconds (0.0016 milliseconds).

Improvement

That being said, the code posted by the OP can be significantly improved for performance by not calling MethodBase.GetCurrentMethod() twice, since what we want are two members of the same object.

The OP's code (with some formatting) = ~3200ns in two MethodBase.GetCurrentMethod() calls:

Log(String.Concat(MethodBase.GetCurrentMethod().DeclaringType.Name, ".", MethodBase.GetCurrentMethod().Name, " : Error is blah blah");

Which can perform twice as fast by simply passing the reference to the MethodBase object to the event log writing method = ~1600ns in one MethodBase.GetCurrentMethod() call:

EventLogWrite(MethodBase.GetCurrentMethod(), "Error is blah blah");

And the event log writing method:

public static void EventLogWrite(MethodBase methodBase, string zErrorMessage)
{
    string classname = methodBase.DeclaringType.Name;
    string methodname = methodBase.Name;

    string logmessage = String.Concat(classname, ".", methodname, " : ", zErrorMessage);

    // ... write message to event log file
}

Plus with this design you don't need to type all of that String.Concat and field separators in every instance of the call to the event log writing method.

deegee
  • 1,553
  • 14
  • 13
  • Also, if the error occurs in a catch statement, such as a `catch (Exception e)`, you can use the `e.TargetSite` member, which returns a MethodBase object, to pass on to the error logging method. – deegee Aug 12 '13 at 04:15
  • Regarding `MethodBase.GetCurrentMethod().DeclaringType.Name` throwing a `NullReferenceException`, I could not find any information on this on MSDN stating that it has any exceptions. However, if accessing these members is performed within a unified event log method such as EventLogWrite shown above, then it is simple enough to trap any errors there and supply a default value. – deegee Aug 13 '13 at 16:59
0

We can use the Stack Trace

Using System.Diagnostics;
// get call stack
StackTrace stackTrace = new StackTrace();

// get calling method name
Console.WriteLine(stackTrace.GetFrame(1).GetMethod().Name);

From How can I find the method that called the current method?

Community
  • 1
  • 1
now he who must not be named.
  • 9,166
  • 26
  • 81
  • 144