Question

We have been using log4net for logging our asp.net web forms application. Our logging is typically in our business layer and the typical implementation is like this

SomeMethodCall(MethodParams)
{
  Log.Start("Starting Some Method");
  try
  {
   //do something
  }
  catch(Exception ex)
  {
    Log.Exception("exception in SomeMethodCall" + ex.message);
  }

  Log.End("End SomeMethod");
}

In my opinon, it is a bit clumsy. Is there a cleaner way of doing it without using AOP ?I am not sure if I would need to have the overhead of adding a framework, just for logging, thought I understand that it would give me a lot of other options (which I do not need)

I am thinking of using some AOP frameworks to do it in a more cleaner way, just by marking the methods with attributes to log and handle exceptions.

There are 2 things I am concerned with AOP (after my initial reading).

Some frameworks inject code into your IL(as per my understanding) and am concerned if it would misguide me. I might be looking at line x, given by my AOP framework, where as it actually might be line y in my application. Is my fear unfounded?

Performance: How much of a performance overhead would be added if using an AOP framework.

Edit: I was also looking into PolicyInjectionApplicationBlock. Unfortunately, I do not have the luxury of changing implementaions inside my business logic

Answer 1

Are you saying that most / all of your methods take this structure? If so, my advice would be to tone down your logging. (I stress that this is advice, and possibly controversial advice as well).

There shouldn’t really be a need to use a blanket log of the entry and exit of every single method in this way, instead place your log entries more strategically. I like to ensure that all log messages have a “purpose” – if I can’t think of a scenario where that log message would help or aid me in some way while debugging then it has no business being in my code!