DEV Community: Ashiqul

Ensure ActionExecutionDelegate is invoked from ASP.NET Core filter

Ashiqul — Fri, 13 Aug 2021 10:37:54 +0000

Developers might forget to invoke ActionExecutionDelegate from ASP.NET Core filter IAsyncActionFilter.OnActionExecutionAsync. Which is essential for the HTTP request to go through the whole pipeline. So forgetting to invoke ActionExecutionDelegate will essentially terminate the request processing through the pipeline.

For ease I use following abstract base class which just wraps the interface and ennsures ActionExecutionDelegate is being invoked.

public abstract class BaseAsyncActionFilter : IAsyncActionFilter
{
    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        await OnActionExecutionAsync(context);

        await next();
    }

    protected abstract Task OnActionExecutionAsync(ActionExecutingContext context);
}

Following xunit test verifies that ActionExecutionDelegate will be invoked.

[Fact]
public async Task OnActionExecutionAsync_Should_Invoke_Action_Execution_Delegate()
{
    // Arrange

    // setup fixture (using nuget package AutoFixture)

    var fixture = new Fixture(); 
    fixture.Register(() => new ParameterDescriptor());
    fixture.Customize(new AutoMoqCustomization());

    var hasActionExecutionContextInvoked = false;

    Task<ActionExecutedContext> Next()
    {
        hasActionExecutionContextInvoked = true;

        return Task.FromResult(fixture.Create<ActionExecutedContext>());
    }

    var sut = new SpyBaseAsyncActionFilter();

    // Act

    await sut
        .OnActionExecutionAsync(fixture.Create<ActionExecutingContext>(), Next);

    // Assert

    hasActionExecutionContextInvoked.ShouldBeTrue();
}


public class SpyBaseAsyncActionFilter : BaseAsyncActionFilter
{
    protected override Task OnActionExecutionAsync(ActionExecutingContext context)
    {
        return Task.CompletedTask;
    }
}

C# : Avoid == && != to check for nullability

Ashiqul — Mon, 01 Feb 2021 07:38:07 +0000

In everyday programming, we have to do something like the following because we don't want to see the ugly NullReferenceException

var car = new Car();

if(car != null) 
{ 
    // invoke method on car variable 
}

Every programmer knows it's the right approach to avoid NullReferenceException.

But is it?

Interestingly enough, if we think about using == or != it becomes apparent very quickly using these operators is not the proper way to check if a variable is null or not because, in C#, we have operator overloading. See the following example:

public class Car
{
    public static bool operator ==(Car lhs, Car rhs) => true;

    public static bool operator !=(Car lhs, Car rhs) => !(lhs == rhs);
}

For this implementation we will have inappropriate results for null checking as demonstrated below:

[Fact]
public void CSharp_Runtime_Should_Return_True_Provided_That_Variable_Is_Not_Null()
{
    var car = new Car();
   (car == null).ShouldBeTrue();
}

[Fact]
public void CSharp_Runtime_Should_Return_False_Provided_That_Variable_Is_Not_Null()
{
    var car = new Car();
   (car != null).ShouldBeFalse();
}

Then what's the solution?

Use is & is not operator combination as shown below:

[Fact]
public void CSharp_Runtime_Should_Return_False_Provided_That_Variable_Is_Not_Null()
{
    var car = new Car();
    (car is null).ShouldBeFalse();
}

[Fact]
public void CSharp_Runtime_Should_Return_True_Provided_That_Variable_Is_Not_Null()
{
    var car = new Car();
    (car is not null).ShouldBeTrue();
}

Use is { } expression as below:

[Fact]
public void CSharp_Runtime_Should_Return_True_That_Variable_Is_Not_Null_Using_Property_Pattern_Matching()
{
    var car = new Car();
    (car is { }).ShouldBeTrue();
}

[Fact]
public void CSharp_Runtime_Should_Return_False_That_Variable_Is_Null_Using_Property_Pattern_Matching()
{
    Car car = null;
    (car is { }).ShouldBeFalse();
}

Note: is { } expression checks if the variable is an instance of object

Use object.ReferenceEquals static method as below:

[Fact]
public void CSharp_Runtime_Should_Return_True_Provided_That_Variable_Is_Not_Null_Using_Reference_Equality_Check()
{
    var car = new Car();
    car.IsNotNull().ShouldBeTrue();
}

[Fact]
public void CSharp_Runtime_Should_Return_False_Provided_That_Variable_Is_Null_Using_Reference_Equality_Check()
{
    Car car = null;
    car.IsNotNull().ShouldBeFalse();
}

...
...
...

public static class ObjectExtensions
{
    public static bool IsNull<T>(this T obj) => ReferenceEquals(obj, null);

    public static bool IsNotNull<T>(this T obj) => !obj.IsNull();
}

Post inspiration: How null checks have changed in C#

Double dispatcher in C#

Ashiqul — Thu, 28 Jan 2021 08:22:04 +0000

Double dispatcher is a feature of some programming languages that allows the runtime to decide which method to invoke/dispatch based on passed arguments type.

Single dispatch

In all C-like programming languages, like C#, virtual is used to facilitate polymorphic behavior. Usage of virtual is a special type of dispatch know as single dispatch. In single dispatch which method will be invoked is decided based on the invoker object's type which is known only in runtime, not compilation time. So for following hierarchy order.IssueOrder(...) will invoke .IssueOrder(..) from type PurchaseOrder provided that var order = new PurchaseOrder().

public interface IOrder
{
    Result IssueOrder(IOrder order);
}
public class SalesOrder : IOrder
{
    public Result IssueOrder(IOrder order) => Result.Ok();
}
public class PurchaseOrder : IOrder
{
    public Result IssueOrder(IOrder order) => Result.Fail("failed");
}

Why single dispatch is not enough?

Consider the following service:

public class OrderIssuerService
{
    public string Issue(IOrder order) => Do(order);

    private string Do(IOrder _) => nameof(IOrder);
    private string Do(PurchaseOrder _) => nameof(PurchaseOrder);
    private string Do(SalesOrder _) => nameof(SalesOrder);
}

What will be the output of the following code block?


//  private readonly ITestOutputHelper _outputHelper;

[Fact]
public void Order_Issuer_Service_Should_Invoke_Method_Taking_IOrder_As_Argument()
{
    _outputHelper.WriteLine(new OrderIssuerService().Issue(new SalesOrder()));
    _outputHelper.WriteLine(new OrderIssuerService().Issue(new PurchaseOrder()));
}

Output

IOrder
IOrder

The important point to note is none of the overloads that take PurchaseOrder or SalesOrder has been invoked. That's because method invocation in C# doesn't depend on the passed argument's type only on the invoker's type.

How can we make C# to invoke the overloads for `PurchaseOrder` and `SalesOrder`?

Approach one: Check for order arguments real type as following

public string Issue(IOrder order)
{
    return order.GetType() == typeof(PurchaseOrder)
        ? Do(order as PurchaseOrder)
        : Do(order as SalesOrder);
}

But checking a type like this is not recommended. It in fact points out a flaw in the design but that's a different topic. So we don't want to cast as such what can we do?

Approach two: Use dynamic keyword

public class OrderIssuerService
{
    public string Issue(dynamic order) => Do(order);

    ...
    ...
}

In this case, C# runtime will invoke the proper overload because dynamic variable holds the original type which is PurchaseOrder/SalesOrder.

Is dynamic recommended to be used in this case?

No. dynamic is generally not a good approach to solve this problem. There are other ways to resolve the issue using visitor pattern but dynamic works :)

An example where employing double dispatcher can be valuable

Consider the following scenario:

public class OrderIssuer
{
    public void Issue(IOrder order) 
    { 
        // complex legacy logic

        MutateOrder(order); 

        // complex legacy logic
    }

    private void MutateOrder(IOrder _) { // complex legacy logic }
}

Let's say there's a bug in the method MutateOrder but it's legacy code and you don't want to touch any of the methods now (maybe your boss forbade you to do so or you are on a deadline). If you know the fix is related to type PurchaseOrder then maybe following can work for you (of course it depends on the code in MutateOrder)

public class OrderIssuer
{
    public void Issue(IOrder order) 
    { 
        // complex legacy logic

        MutateOrder(order); 

        // will invoke the new overload as order is of 
        MutateOrder((dynamic)order); 

        // complex legacy logic
    }

    private void MutateOrder(IOrder _) { // complex legacy logic }
    private void MutateOrder(PurchaseOrder _) { // new logic }
}

This approach obviously has the downside that for SalesOrder 1st overload will be invoked twice but the point is without changing anything in the legacy code we might be able to fix the bug albeit the approach is a dirty approach.