Do you plan to take on .NET MAUI? Get ready for an adventure with NullReferenceException

.NET Multi-platform App UI is a framework written by professionals. However, the code of some of its functions looks like the developers could have forgotten what null reference dereferencing could lead to.

A brief introduction

I can't judge the overall quality of the MAUI project, but I suspect developers will spend quite a bit of time addressing all user reports about unexpected NullReferenceException.

The authors may have been in a hurry to write the code. As a result, some code fragments contain references, which, according to the developers, may be null, and which are not checked for null before dereferencing. To make it clearer, let's take a look at some fragments from the MAUI 6.0.424 source code.

Why so?

When I looked at the fragments I'm listing below, I asked myself the same question. Either I'm missing something, or MAUI developers write very strange code.

Let's take a look at the fragment from the AttachEvents function of the AdaptiveTrigger class:

void AttachEvents()
{
  ....

  _visualElement = VisualState?.VisualStateGroup?.VisualElement;
  if (_visualElement is not null)
    _visualElement.PropertyChanged += OnVisualElementPropertyChanged;

  _window = _visualElement.Window;  // <=
  ....
}

It doesn't make any sense. Judging by the two "?." and the "is not null" check, we may expect null in the _visualElement field. Then the code accesses the Window property, but without first checking _visualElement *for *null. Apparently, someone overlooked it.

Okay, let's move on. Take a look at the fragment from the FormattedString class:

void OnCollectionChanged(....)
{
  ....
    foreach (object item in e.OldItems)
    {
      var bo = item as Span;
      bo.Parent = null;                   // <=
      if (bo != null)
      {
        ....
      }
  .... 
}

The adjacent lines again. First the developers dereferenced bo, and then suddenly decided to check it for null. I'm not sure whether this code crashes in some cases, but it all looks strange.

Here is a snippet from the ListView class:

protected override void SetupContent(Cell content, int index)
{
  ....

  if (content != null)
    _logicalChildren.Add(content);

  content.Parent = this;
  VisualDiagnostics.OnChildAdded(this, content);
}

It's all nonsense again. Why do they perform a null check only when adding an element to the collection, but skip the check when accessing the property?

I found another "useful" null check in the constructor of the ShellChromeGallery class:

AppShell AppShell => Application.Current.MainPage as AppShell;

public ShellChromeGallery()
{
  ....

  if (AppShell != null)
  {
    flyoutBehavior.SelectedIndex = ....;
    flyoutHeaderBehavior.SelectedIndex = ....;
  }
  else
  {
    flyoutBehavior.SelectedIndex = 1;
    flyoutHeaderBehavior.SelectedIndex = 0;
  }

  AppShell.FlyoutBackdrop = SolidColorBrush.Pink;  // <=
}

Here we go again: we check for null, set some default values if necessary, and then crash immediately.

Considering how often I encountered strange fragments, I even began to think that checking for null was not what it seemed. Take, for example, Unity: the "==" operator is overloaded and the null check works there in a peculiar way intentionally. However, I didn't see anything like that in MAUI.

Why is it so anyway?

MAUI is written by professionals, but the project is very big and complex. People make mistakes, and that's okay. The strange thing is, the project contains such problems despite the fact that various automated tools can catch them. It's not hard to guess that I used the PVS-Studio static analyzer for C# to find these fragments. In my opinion, such tools would simplify the life of MAUI developers. In any case, I wish them success with the development of the project.