Search  
Always will be ready notify the world about expectations as easy as possible: job change page
Nov 22, 2023

How returning NULL leads to snitchy bugs and how to prevent them

Author:
Source:
Views:
1530

There is a simple solution just around the corner

Returning NULL horror

Null as a return value is so easy to implement, but it brings many problems. So people make mistakes. That is part of being human. Sometimes it turns out to be a billion-dollar mistake.

“I call it my billion-dollar mistake. It was the invention of the null reference in 1965.” — Tony Hoare — British Turing Award winner Tony Hoare at a conference in 2009.

Every developer will probably have had a NullReferenceException or something similar blows up in their face. Now you know whom to thank.

So if using NULL has so many drawbacks, why are many of us, including me, also using it so recklessly? And are there better alternatives? Yes, you will see.

The Null Problem

I am sure your problem won’t be worth a billion dollars. 😉 But many do it since Null as a return value is so easy to implement. This is also my guilty pleasure.

Unfortunately, it does not provide any information why no more object was delivered. Imagine calling the API for the database and getting a null return. I instantly think of 3 scenarios that might be wrong:

  • Did the database access fail?
  • Was there a problem with authentication?
  • Is there a missing reference anywhere else my return relied on?

You can never be sure what has happened.

This is a big disadvantage.

Easy to implement. Easy to check. But the handling is the worst!

The consuming code must always include so-called guard clauses. That means any statement that wants to use a potential null object must perform the null check. This results in many if-else branches spread across the entire code base, which increases the cyclomatic complexity.

Your code gets worse and worse to comprehend,

and I dare you to forget only a single null check.

Pulp Fiction Scene — “Say What again, I dare you, I double dare motherfu**er”
Pulp Fiction Scene — “Say What again, I dare you, I double dare motherfu**er”

This brings us back to the null check on returned references.

How to use the Null Object Design Pattern

Ironically, introducing a null object is the first way to avoid null checking.

Consider this as a simple example:

Incoming messages are routed depending on their message type.

The class Message includes an enum to determine their type:

public class Message
{
   public enum Types
   {
      Sms,
      Unknown
   }

   private readonly Types _type;

   public Types Type => _type;

   public Message(Types type)
   {
      _type = type;
   }
}

The routers, which take over the further processing, are implemented by the interface IRouter:

interface IRouter
{
   void Route(Message message);
}

This interface can be inferred to determine concrete implementations of all desired types:

class SmsRouter : IRouter
{
   public void Route(Message message)
   {
      Console.WriteLine("Implementation details for SMS");
   }
}

class MailRouter : IRouter
{
   public void Route(Message message)
   {
      Console.WriteLine("Implementation details for Mail");
   }
}

class ChatRouter : IRouter
{
   public void Route(Message message)
   {
      Console.WriteLine("Implementation details for Chat");
   }
}

The following factory generates the router that matches the type of the Message or returns null in the initial implementation if a message type is unknown.

class RouterFactory
{
    public IRouter GetRouter(Message.Types messageType)
    {
        if (messageType == Message.Types.Sms) return new SmsRouter();
        if (messageType == Message.Types.Mail) return new MailRouter();
        if (messageType == Message.Types.Chat) return new ChatRouter();

        return null;
    }
}

So this is the typical code that quickly makes problems. You will see what happens when you write the calling code.

I defined an array of Messages and looped through them to get the matching router for each message type:

var messages = new Message[]
{
   new(Message.Types.Sms),
   new(Message.Types.Mail),
   new(Message.Types.Chat),
   new(Message.Types.Unknown),
};

foreach (var msg in messages)
{
   new RouterFactory().GetRouter(msg.Type).Route(msg);
}

And this stuff throws the console at me for the unknown type:

Implementation details

This is a runtime error nightmare and would be easily avoidable by using the Null Conditional Operator:

new RouterFactory().GetRouter(msg.Type)?.Route(msg);

But then you end up in the same situation again.
I dare you always remember to implement just a single one of these.

So what now?

Your goals are:

  • Avoid checking for null actively.
  • In case of a null return — the code runs smoothly without crashing.

You can achieve this by creating an automatic RoutingHandler that returns a NullObjectRouter that you define:

public class NullObjectRouter : IRouter
{
    private static readonly NullObjectRouter _instance = new NullObjectRouter();
    public static NullObjectRouter Instance => _instance;

    private NullObjectRouter()
    {
    }

    public void Route(Message message)
    {
        Console.WriteLine("No router for message type of {0}. Do nothing.",
        message.Type);
    }
}

Since you have your failsafe NullObjectRouter, you can quickly build a Handler on top of your adapted factory from before. Simply ensure to return NullObjectRouter.Instance instead of null:

class RouterFactory
{
   public IRouter GetRouter(Message.Types messageType)
   {
      if (messageType == Message.Types.Sms) return new SmsRouter();
      if (messageType == Message.Types.Mail) return new MailRouter();
      if (messageType == Message.Types.Chat) return new ChatRouter();

      return NullObjectRouter.Instance;
   }
}

Then implement the wrapper for the factory, and you can handle every type of Message automatically without any null checks:

public class RoutingHandler
{
   private readonly RouterFactory _factory = new RouterFactory();

   public void Process(IEnumerable<Message> messages)
   {
      foreach (var msg in messages)
      {
         _factory.GetRouter(msg.Type).Route(msg);
      }
   }
}

Your possible calling code:

var messages = new Message[]
{
   new(Message.Types.Sms),
   new(Message.Types.Mail),
   new(Message.Types.Chat),
   new(Message.Types.Unknown),
};

new RoutingHandler().Process(messages);

Implementation details

This adaptation eliminates null checks in the implementation of the RoutingHandler, which is the Factory supplies by this adjustment, in each case, an instance of IRouter.

Identify Code Smells With Ease and Replace Them With Best Practice Patterns. Get the “All Code Smells As One-Liner”-Cheatsheets.

References

Similar
Jan 8
Author: Dr Milan Milanović
“Application Programming Interface” or API, refers to a communication channel between various software services. Applications that transmit requests and responses are called clients and servers, respectively.There are different types of API protocols: REST — relies on a...
Apr 28, 2022
Author: Julia Smith
Table Of Content- Introduction- Top 6 Tips to optimize the performance of your .Net application- 1. Avoid throwing exceptions- 2. Minify your files- 3. Avoid blocking calls- 4. Cache your pages- 5. Optimize custom code- 6. Minimize large object allocation-...
May 13, 2023
Author: Juan Alberto España Garcia
Introduction to Async and Await in C#Asynchronous programming has come a long way in C#. Prior to the introduction of async and await, developers had to rely on callbacks, events and other techniques like the BeginXXX/EndXXX pattern or BackgroundWorker.These methods...
Jul 16, 2021
Author: Robert Sheldon
SQL Server performance tuning can seem overwhelming when you don’t know where to start. In this article Robert Sheldon explains 9 best practices for performance tuning.SQL Server is a powerful and feature-rich database management platform that can support a wide...
Send message
Email
Your name
*Message


© 1999–2024 WebDynamics
1980–... Sergey Drozdov
Area of interests: .NET Framework | .NET Core | C# | ASP.NET | Windows Forms | WPF | HTML5 | CSS3 | jQuery | AJAX | Angular | React | MS SQL Server | Transact-SQL | ADO.NET | Entity Framework | IIS | OOP | OOA | OOD | WCF | WPF | MSMQ | MVC | MVP | MVVM | Design Patterns | Enterprise Architecture | Scrum | Kanban