Здравствуйте, licedey, Вы писали:

L>В CodeContracts в довесок еще и рантайм проверки идут. Правда непонятка чем это лучше, чем скажем Debug.Assert(something != null);

Оно там не само по себе, а в комплекте. Где удается устранить — там устраняется, где не удается — остается рантайм проверка.

Здравствуйте, licedey, Вы писали:

L>Любой бывалый разработчик подтвердит — NullReferenceException (сокращенно NLP) — самая распространенная ошибка в любой проге. Так что давно пора эту фичу вносить.
Ну вот не знаю... NRE — ошибка частая, но по моей практике в 99% случаях она не от того, что кто-то где-то забыл инициализировать, а от того, что какой-нибудь метод вернул null.
Либо это свой метод, где просто забыли, что может быть и null, либо библиотечный, где по незнанию null иногда не ожидают (типа, Directory.GetDirectoryName).
Вот на возвращаемые значения аннотаия [NotNull] с предупреждением компилятора бы не помешала (хоть и не спасла бы).
А какие-то средства языка или типы специально для этого — не нужно, будет только больше путаницы.

Здравствуйте, bazis1, Вы писали:

B>Идея такая. Представь себя на месте юзера. Вот пользуешься ты некоторой программой, попытался создать в ней новый документ и вдруг получил NullReferenceException. Что его вызвало — непонятно. Да и разработчики без дампа (или хотя бы stack trace) мало чем смогут помочь. Если бы вместо этого программа выдала "Exception: template file does not exist", ты бы сразу смекнул "наверное, это была прохая идея удалить normal.dot, чтобы освободить 1 килобайт на диске".
Угу, а потом тут же приходят аналитики и верхние менеджеры, которые говорят, что "почему это у вас пользователю показываются технические сообщения? Это нехорошо. Это не обязанность пользователя читать такие сообщения".
И после этого программа начинает вместо этого выдавать: "Программа сделала что-то нехорошее и на всякий случай будет закрыта, позовите администратора, он разберётся". А администратор и сам ничего понять не может. так как сообщение ни о чём, а логов нормальных нет. Либо они есть, но где-нибудь на сервере, где другой администратор и вообще другая организация.
В общем, это к тому, что для конечного пользователя всё равно ничего не поменяется.

Здравствуйте, vmpire, Вы писали:

V>Вот на возвращаемые значения аннотаия [NotNull] с предупреждением компилятора бы не помешала (хоть и не спасла бы).
V>А какие-то средства языка или типы специально для этого — не нужно, будет только больше путаницы.

Вот в таком виде мне это нравится намного больше!
Вместо загромождения кода "атрибутами для бестолковых индусов", будет две вещи: [NotNull] для возвращаемых значений + компилятор будет проверять, что переменная получает non-null инициализацию перед использованием.

В моей практике я весьма редко огребаю NRE, чаще капризничают конструкторы с неправильными аргументами.

К слову, упомянутая string.Substring — пример, за который можно увольнять практически сразу — какая-то бестолочь вместо пары проверок выхода за границы И КОРРЕКЦИИ ГРАНИЦ, предпочла капризно бросаться иксепшенами, портя кровь практически 100% разработчиков. Пример:

var s = UserInput();
var FirstTwoLetters = s.Substring(0, 2);
if (FirstTwoLetters == "RU") ...

Вот скажите, ну не всё равно, ЧТО там ввёл юзер и какой длины? Важно то, что даже если он ввёл что-то некорректное, мы УМЕЕМ обрабатывать этот случай. Сейчас же ты, вместо бизнес задач, вынужден танцевать вокруг идиота, писавшего substring, чтоб не дай бог ты не запросил длину больше, чем строка! Катастрофа, полундра, собирайте весь коллектив, будем разбирать, зачем Володька сбрил усы!
Это как раз пример того, чего мы ДОЛЖНЫ избежать, занимаясь non-null магией — чтобы юзерский код не превращался в месконечную мешанину проверок там, где их спокойно можно опустить.