Scheisse

[metaclass]

Как же не хватает в дотнете типа StringNotNull. Чтобы быть гарантированно уверенным, что параметр не может быть null и не проверять в 100 методах его перед обработкой.

Comments

[kashnikov.livejournal.com]

Кто мешает добавить?

[kashnikov.livejournal.com]

А Вы какое поведение хотите, если можно то хотя бы вкратце?

[enternet.livejournal.com]

Что-то ты не то обрабатываешь.

Проверять обычно или:

1) нужно. Не этот случай, проехали.
2) НЕ НУЖНО. Никому нахер не нужна обработка "ААА! Параметр нулевой!". Один вред от такого кода.
3) нужно, но по хитрому. Тогда я обычно юзаю хелперы (this)

псевдокод:
public static string Scheisse(this string paramName)
{
if (paramName == null)
return 'Scheisse'
else
return paramName;
}

[wizzard]

Microsoft Contracts, F# или хелперы.

[xeno-by.livejournal.com]

Это как const в плюсах. Когда хоть где-то возникают нот-налл типы, они просачиваются во всю прилагу. А когда просачиваются, то возникают вопросы, например:

1) Что делать с неинициализированными филдами классов в момент вызова конструктора? С одной стороны, если какие-то из них помечены как not-null, то как же тогда выполнять тело конструктора - ведь в какой-то момент (до присваивания этому филду значения) контракт будет нарушен.

2) Что делать с вызовами базового конструктора? С одной стороны, хочется сделать как обычно - выполнить его до конструктора наследника, но если у наследника есть филд not-null, ну дальше понятно.

3) Веселые косяки ждут дизайнера языка, если он решит консистентности ради разрешить массивы not-null типов. Тот же вопрос - что делать с инициализацией?

Кароче - в языках, где возможны частично инициализированные объекты, например, во всех ОО-языках, введение not-null типов порождает или неиллюзорный гемор, или неконсистентность, или и то, и другое.

[dev-pit.livejournal.com]

Дак и не надо его в 100 методах проверять, только в одном public :)