Планируете взяться за .NET MAUI? Будьте готовы к приключениям с NullReferenceException
.NET Multi-platform App UI — фреймворк, который пишут профессионалы. Тем не менее, код некоторых его функций выглядит так, будто разработчики забыли о последствиях разыменования нулевых ссылок.
Небольшая вводная
Не берусь судить об общем качестве проекта MAUI, но у меня есть сильные подозрения, что проекту предстоит пройти долгий путь фиксов по фидбеку от пользователей про неожиданные NullReferenceException.
Код создаёт впечатление, что авторы очень торопятся при его написании. Из-за этого во многих местах без проверок разыменовываются ссылки, которые, по мнению самих же разработчиков, могут быть нулевыми. Чтобы было понятнее, давайте взглянем на отдельные фрагменты из исходников MAUI 6.0.424.
Почему так?
Именно этот вопрос я задавал себе, когда глядел на фрагменты, представленные далее. Либо я чего-то не понял, либо разработчики MAUI пишут очень странный код.
К примеру, взгляните на фрагмент из функции AttachEvents класса AdaptiveTrigger:
void AttachEvents()
{
....
_visualElement = VisualState?.VisualStateGroup?.VisualElement;
if (_visualElement is not null)
_visualElement.PropertyChanged += OnVisualElementPropertyChanged;
_window = _visualElement.Window; // <=
....
}
Тут выходит какая-то ерунда. Судя по двум »?.» и проверке «is not null», в поле _visualElement может быть null. И буквально тут же мы видим обращение к свойству Window, но уже без проверки. Видимо, проглядели.
Ладно, идём дальше. Взгляните на фрагмент из класса FormattedString:
void OnCollectionChanged(....)
{
....
foreach (object item in e.OldItems)
{
var bo = item as Span;
bo.Parent = null; // <=
if (bo != null)
{
....
}
....
}
Опять соседние строчки. Сначала разыменовали bo, а затем вдруг решили проверить его на null. Я не знаю, падает ли этот код в каких-то случаях, но выглядит это всё странно.
А вот кусочек из класса ListView:
protected override void SetupContent(Cell content, int index)
{
....
if (content != null)
_logicalChildren.Add(content);
content.Parent = this;
VisualDiagnostics.OnChildAdded(this, content);
}
Тут снова какая-то ерунда. Почему в коллекцию элемент добавляется с проверкой, а к свойству мы обращаемся уже без неё?
Ещё одну «полезную» проверку на null я нашёл в конструкторе класса ShellChromeGallery:
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; // <=
}
Ну тут опять всё круто: проверяем на null, выставляем при необходимости какие-то дефолтные значения, а потом сразу же падаем.
Учитывая то, как часто попадаются странные фрагменты, я даже начал думать, что проверка на равенство null — совсем не то, чем кажется. Ну, к примеру, в том же Unity оператор »==» перегружен и проверка на равенство null там работает по-особому. Однако в MAUI ничего такого я не увидел.
А почему же всё-таки так?
MAUI пишут профессионалы, но проект очень уж большой и сложный. Люди ошибаются, и это нормально. Странно другое: такие проблемы вполне могут отлавливать различные автоматизированные инструменты. К примеру, как несложно догадаться, я нашёл показанные фрагменты с помощью C# анализатора PVS-Studio. На мой взгляд, подобные инструменты сильно бы упростили жизнь разработчикам MAUI. А в целом желаю им успехов с развитием проекта.
Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Nikita Lipilin. Do you plan to take on .NET MAUI? Get ready for an adventure with NullReferenceException.
