vkhorikov Sep 17 2015 at 14:15

Functional C#: Non-nullable reference types (ненулевые ссылочные типы)

5 min

20K

Programming*.NET*C#*ООP*Functional Programming*

+11

Comments 12

impwx Sep 17 2015 at 18:07

Получается, что все проверки на null, даже будучи автоматически добавленными в код, выполняются все равно в рантайме.
Не лучше ли использовать Resharper с аннотациями, или Code Contracts, чтобы получить аналогичные проверки во время компиляции?

vkhorikov Sep 17 2015 at 18:11

Не совсем так. Проверка на нал действительно идет в ран-тайме, но мы получаем ошибку компилятора в случае если используем нулевую ссылку там где подразумевалась ненулевая.
Code annotations от решарпера мне не нравятся тем, что
1) Это всего лишь warning
2) Используется opt-in схема. Т.е. все типы по умолчанию нулевые. По-хорошему нам нужно обратное поведение — сделать все типы по умолчанию ненулевыми и затем opt-out в случае если какой-то из них нулевой.

Но вообще Code annotations и Code Contracts — тоже вполне себе хорошая альтернатива

impwx Sep 17 2015 at 18:32

1. Можно настроить, чтобы предупреждение считалось ошибкой.
2. Да, так вроде бы нельзя — атрибуты все равно нужны.

Кстати, правильно ли я понял из ваших примеров, что проверяется только значение полей?
Значит, если сам объект будет нулевым, то Null Reference все равно возникнет?

var customer = CustomerService.GetCustomer(); // вдруг вернуло Null?
Console.WriteLine(customer.Name); // все равно будет NRE

vkhorikov Sep 17 2015 at 18:42

1. Согласен

Проверяются все входящие и выходящие значения. Т.е. в вашем примере NRE будет тут:

var customer = CustomerService.GetCustomer(); // будет NRE
Console.WriteLine(customer.Name);

alexanderzaytsev Sep 21 2015 at 12:28

>2. Да, так вроде бы нельзя — атрибуты все равно нужны.

Можно github.com/ulrichb/ImplicitNullability

vkhorikov Sep 17 2015 at 19:09

Еще хотел добавить. Пожалуй главный плюс подхода с Maybe для меня в том, что он улучшает читаемость кода благодаря тому, что мы разделяем нулевые и ненулевые типы.

DrReiz Sep 17 2015 at 22:42

Зачем необходима борьба с null-ом? Если достаточно написать: Console.WriteLine(customer?.Name).

UFO just landed and posted this here

impwx Sep 18 2015 at 10:10

Вообще говоря, это не решает проблему. В вашем примере непосредственно ваш код не падает, но метод WriteLine все равно вызывается и в него передается null. Если бы это был другой метод, который передает значение куда-то глубоко вниз по цепочке вызовов и там вдруг возникает NullReferenceException, отлаживать такую ситуацию может быть затруднительно.

DrReiz Sep 18 2015 at 12:33

Null reference затруднительно отлаживать в mutable-окружении. В таком окружении бывает затруднительно установить место появления null-а. В immutable-коде такой проблемы нет из-за прозрачности потоков данных.

divan-9th Sep 18 2015 at 21:46

Выглядит классно, но в свой боевой проект внедрять побоюсь. Автор сам указал на проблему с использованием фреймворков, и это не позволит кодировать разные сборки в составе солюшена в одном стиле. Мне кажется, это может усложнить чтение кода для членов команды или сторонних ревьюверов.
Может быть это надуманная проблема, но я много раз наблюдал сложности с пониманием даже достаточно простых вещей людьми, которых сложно назвать глупыми, всего лишь из-за разницы в стиле кодирования.

Trueteller Sep 19 2015 at 13:16

Maybe вполне можно использовать и без Fody, с сочетанием соглашения не возвращать null и ручных проверок.
Мне больше нравится реализация Maybe на основе IEnumerable: очень удобно использовать в LINQ выражениях.
Стоит отметить, что в F# Maybe называется «option».

Show the best of all time