C# Overloading Action & Func and why {} matters

Basics - Overloading

Let us start with basics of overloading. Will the below code compile?

class SomeClass
{
    void Execute()
    {
 
    }
    int Execute()
    {
        return 10;
    }
}

Certainly not. We know that overloading applies to the arguments. Return type is not considered.

Now look at below code. Will it compile?

internal class SomeClass
{
    void Execute(Action handler)
    {
    }
    int Execute(Func<int> worker)
    {
        return worker() ;
    }
}

Don't spend more time. It will compile. For sure. Will it work as expected? That is tricky question. As of our understanding, we are using strong typed languages to avoid many runtime type related issues. So that we can concentrate on our logical issues more.

Consider the below code and guess what happens

internal class SomeClass
{
    internal void Test()
    {
        this.Execute(() =>  Console.WriteLine("Hi"));
    }
    void Execute(Action handler)
    {
        Console.WriteLine("Inside Execute(Action)");
        handler();
    }
    int Execute(Func<int> worker)
    {
        Console.WriteLine("Inside Execute(Func)");
        return worker() ;
    }
}

SomeClass cls = new SomeClass();
cls.Test();

The output will be
Inside Execute(Action)
hi

The problem

If we call Execute as shown below which function will execute?

internal class SomeClass
{
    int num = 0;
    internal void Test()
    {
        this.Execute(() =>  num++);
    }
    void Execute(Action handler)
    {
        Console.WriteLine("Inside Execute(Action)");
        handler();
    }
    int Execute(Func<int> worker)
    {
        Console.WriteLine("Inside Execute(Func)");
        return worker() ;
    }
}

SomeClass cls = new SomeClass();
cls.Test();

The output will be 

Inside Execute(Func)

Why did this happen? Since the C# language support lambda expressions without explicit return value which is just there it assumed that the intention is to return the incremented value. Sometimes the original intention of developer might be just to increment the num variable. Some conflict happened between the developer and the language.

This is kind of OK scenario. Nothing breaks. Lets see little more complex scenario where it cause trouble.

internal class SomeClas
{
    int value = 0;
    internal void Test()
    {
        this.Execute(() => value++ );
    }
    void Execute(Action handler)
    {
        Console.WriteLine("Inside Execute(Action)");
        handler();
        CleanUp();
    }
 
    int Execute(Func<int> worker)
    {
        Console.WriteLine("Inside Execute(Func)");
        int result = 0;
        Execute(() => result = worker());
        return result;
 
    }
    private void CleanUp()
    {
        Console.WriteLine("CleanUp");
    }
}

The developer wants to do some cleanup after Execute. So he added the CleanUp() inside action and he wanted to avoid CleanUp() in all the other functions. Other functions pass action to so that the CleanUp() will be performed for all the Execute() calls. 

The expected output event with call to Execute(<Func>) is

Inside Execute(Func)

InsideExecute(Action)

Hi

But what happens here is infinite loop. Some clever language geeks might have foreseen thie infinite loop. But normal developer will not.

Fix - Use curly brackets / braces / {}

People think that putting {} is time waste and they avoid it where ever possible. But here it would have saved some time. See the fix below.

internal class SomeClas
{
    int value = 0;
    internal void Test()
    {
        this.Execute(() => value++ );
    }
    void Execute(Action handler)
    {
        Console.WriteLine("Inside Execute(Action)");
        handler();
        CleanUp();
    }
 
    int Execute(Func<int> worker)
    {
        Console.WriteLine("Inside Execute(Func)");
        int result = 0;
        Execute(() => { result = worker(); });
        return result;
 
    }
    private void CleanUp()
    {
        Console.WriteLine("CleanUp");
    }
}

Just adding {} into lambda expressions helps us a lot. If Test() used {} it would have avoided one more function call and could have reached to Execute(Action) directly.

Moral of the story is don't hate braces. Omitting those is not going to save lot of time or decrease size of program.

Considering the API

But please be aware that if we are giving these Execute() methods as APIs there is no guarantee that our customers will use {} always. So we have to overload the functions properly.