Create an Attribute which will treat the decorated method as a delegate

Question

Preamble/Context

So currently I have a Log method.

public T Log<T>(Func<T> func)
{
    string methodName = func.Method.Name;
    bool success = false;
    T product = default(T);

    Debug($"Entering {methodName}");

    try
    {
        product = func.Invoke();
        success = true;
    }
    catch (Exception e)
    {
        Info($"FAILURE: {methodName}: {e.Message}");
    }

    Debug($"{success.ToString().ToUpper()}: Exiting {methodName}");
    return product;
}

Which works really well for me and is called like this

Log(() => AddTwoNumbers(1, 2));

I've been using the decorator pattern and basically saying that all the methods of the interface call their base (or the contained object or however you want to go about implementing the base method) so that the methods are logged.

DISCLAIMER I don't have easy access to AOP in my situation so generating a proxy that handles this isn't an easy route. I'm mostly overhauling legacy code and making calls to my .NET libraries from Visual Basic 6 EXEs and from what I can see most of these AOP frameworks need to be incorporated directly into the app.

The Problem I'm Trying to Solve

Many times I find myself doing this:

public int AddFirstFourNumbers(params int[] numbahs) 
{
  Log(() => 
  {
    int product;
    product += numbahs[0];
    product += numbahs[1];
    product += numbahs[2];
    product += numbahs[3];

    return product;
  }
}

Or decorating all members of an extension class like this

public override int AddTwoNumbers(int num1, int num2)
{
  return Log(() => base.AddTwoNumbers(num1, num2));
}

and I'd like to turn that into this:

[Log]
public int AddFirstFourNumbers(params int[] numbahs) 
{
    int product;
    product += numbahs[0];
    product += numbahs[1];
    product += numbahs[2];
    product += numbahs[3];

    return product;
}

and this

[Log]
public override int AddTwoNumbers(int num1, int num2)
{
  return base.AddTwoNumbers(num1, num2);
}

I'm not very familiar with creating custom Attributes but is there a way to treat the method decorated by this log attribute as a delegate and pass it to the Log method described in the first block? The examples I see on the Microsoft Docs don't seem to do anything close to what I'm hoping for.

https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/attributes/creating-custom-attributes

At the same time we have the MVC validation attributes which seem to provide tons of helpful functionality so this may yet be possible.

I'm a huge fan of Action and Func Wrappers that allow me to decorate my base methods and separate out my concerns. I'm just looking for a cleaner way of doing so. It would be nice to be able to just add [WithImpersonation] to the top of a method or [UndoOnFailure] and only display the core implementation within the actual method block.

Answer 1

First, I want to talk about the problem you'll have using the attribute approach. Assume you have a method AddFirstFourNumbers decorated with the Log attribute, as described in your question.

The attribute exists as metadata on the method. That's it. Any methods it contains will only be called if you specifically call them. In other words:

var attrib = typeof(ClassWithAddFirstFourNumbers)  // get the attribute
    .GetMethod(nameof(AddFirstFourNumbers))
    .GetAttributes<LogAttribute>()
    .FirstOrDefault();

if (attrib != null)  attrib.BeforeLog();
AddFirstFourNumbers(somenumbers);
if (attrib != null)  attrib.AfterLog();

Now, you could use your lambda approach to make a method that gets this attribute, but you would have to go the expression tree approach (linked below) to get the attribute from inside the lambda call. And now you have an attribute for no real reason. Not fun.

I present this as an alternative. I believe you may be overthinking this.

First, Your Log method, as implemented, won't get the name of the method you're passing into the lambda. You can change how you get the method name by using expressions, but this will mean your lambda calls can't be much more than a single method call, not groups of methods, or property accesses.

I think you are overusing exception handling. I suggest you catch exceptions at the highest level where you can make a decision about how to handle them. There, you'll have the call stack, which will indicate where the exception occurred. You generally do not need to log exceptions where they happened, unless you need to log variables to understand the cause of the exception. (KeyNotFoundException doesn't tell you which key wasn't found!) A general-purpose logging system, as you propose in your question, wouldn't -- couldn't -- grab these variables.

This is more subjective opinion, but I feel that you are overthinking this a bit. This is my recommendation. Keep it simple, and just add some logging to your methods:

public int AddFirstFourNumbers(params int[] numbahs) 
{
    int product;
    product += numbahs[0];
    product += numbahs[1];

    Debug("Still adding numbers but we'll require additional pylons soon");

    product += numbahs[2];
    product += numbahs[3];
    return product;
}

And:

var sum = AddSomeNumbers(somenumbers);
Debug($"{nameof(AddSomeNumbers)} on {somenumbers.Length} numbers -> {sum}");

This allows greater flexibility and utility in your log messages, and doesn't litter your code much more than the lambda approach. This means you'll need to write a log message, but there is no rule they need to all be consistent and fully of juicy debugging tips. Something as simple as Debug($"sum={sum}"); is still useful and doesn't take much time to type.

Okay. This last idea will probably provide you the biggest benefit toward what you want to achieve. Do I have the following stipulations right?

• You want to know where you are logging from. Class and method. Even the line number.

• You'd like to know the thread, or the user.

• You'd like to be able to add additional logging information globally without having to alter your code.

• You'd like to be able to add additonal logging information to specific classes or namespaces, without having to alter your code.

Use a library like NLog, log4net, Serilog, or others. They're all very good. All of them will let you define a global pattern for your log messages: class name, method name, thread id, user name, timestamp, an environment variable, etc. I am most familiar with NLog, which provides these as layout renderers. I will show you how this works using NLog.

public class YourExampleClass
{
    private static readonly Logger Logger = LogManager.GetCurrentClassLogger();

    public void ExampleMethod()
    {
        try
        {
           Logger.Info("Hello world");
        }
        catch (Exception ex)
        {
           Logger.Error(ex, "Goodbye cruel world");
        }
    }
}  

With that code, the other information I specified, like location and timestamp, are added in configuration using the layout renderers. Neat, huh? This would not require large scale alterations to your program. You can log from the classes you need to log from, and other classes won't be altered.

For your convenience, here is the official NLog tutorial.