Pour obtenir une clé
d'essai remplissez le formulaire ci-dessous
Demandez des tariffs
Nouvelle licence
Renouvellement de licence
--Sélectionnez la devise--
USD
EUR
RUB
* En cliquant sur ce bouton, vous acceptez notre politique de confidentialité

Free PVS-Studio license for Microsoft MVP specialists
To get the licence for your open-source project, please fill out this form
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

I am interested to try it on the platforms:
** En cliquant sur ce bouton, vous acceptez notre politique de confidentialité.

Votre message a été envoyé.

Nous vous répondrons à


Si vous n'avez toujours pas reçu de réponse, vérifiez votre dossier
Spam/Junk et cliquez sur le bouton "Not Spam".
De cette façon, vous ne manquerez la réponse de notre équipe.

>
>
>
Do you plan to take on .NET MAUI? Get r…

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

06 Oct 2022

.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.

0996_NRE_MAUI/image1.png

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.

Latest articles:

Poll:

Comments (0)

Next comments
Unicorn with delicious cookie
Nous utilisons des cookies pour améliorer votre expérience de navigation. En savoir plus
Accepter