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

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

Теперь давай смотреть, почему вместо осмысленного exception-а вылез обычный NullReferenence. В 99% случаев паттерн будет такой:

SomeClass LoadSomething()
{
    if(something)
        return null;
}

//...

SomeClass obj = LoadSomething();
obj.DoSomething(); // <== Вот тебе бабушка и NullReferenceException

Почему это происходит? Заговор программистов? Попытка свергнуть режим? Тайное общество почитателей Null-а?
Нет, все проще. Человек, который писал LoadSomething(), подумал, что проверку на null сделают в вызывающем коде, а человек, который писал вызов, подумал, что LoadSomething() сам бросит осмысленный Exception.

Соответственно, поменяется с приходом Non-nullable? LoadSomething() можно будет объявить как non-nullable, тогда попытка вернуть из него null словится на этапе компиляции. Соответственно, человек, добавивший проверку на if(something) это увидит и быстро поправит:

SomeClass! LoadSomething()
{
    if(something)
        throw new Exception("Something happened. You better run.");
}

С другой стороны, если в проекте договорятся что LoadSomething() сама ничего не бросает и возвращает null, то ее оставят как есть и тогда компилятор сможет с полным правом выдать warning, что вызывать obj.Something() без проверки obj на null нехорошо.

Как-то так.
P.S. Кстати, подобное давно реализовано в тех же Code Contracts от MS, но они за пределами research особо не популярны.

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

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

Теперь давай смотреть, почему вместо осмысленного exception-а вылез обычный NullReferenence. В 99% случаев паттерн будет такой:

SomeClass LoadSomething()
{
    if(something)
        return null;
}

//...

SomeClass obj = LoadSomething();
obj.DoSomething(); // <== Вот тебе бабушка и NullReferenceException

Почему это происходит? Заговор программистов? Попытка свергнуть режим? Тайное общество почитателей Null-а?
Нет, все проще. Человек, который писал LoadSomething(), подумал, что проверку на null сделают в вызывающем коде, а человек, который писал вызов, подумал, что LoadSomething() сам бросит осмысленный Exception.

Соответственно, что поменяется с приходом Non-nullable? LoadSomething() можно будет объявить как non-nullable, тогда попытка вернуть из него null словится на этапе компиляции. Соответственно, человек, добавивший проверку на if(something) это увидит и быстро поправит:

SomeClass! LoadSomething()
{
    if(something)
        throw new Exception("Something happened. You better run.");
}

С другой стороны, если в проекте договорятся что LoadSomething() сама ничего не бросает и возвращает null, то ее оставят как есть и тогда компилятор сможет с полным правом выдать warning, что вызывать obj.Something() без проверки obj на null нехорошо.

Как-то так.
P.S. Кстати, подобное давно реализовано в тех же Code Contracts от MS, но они за пределами research особо не популярны.