GregTk,

Я примерно то же самое хотел написать по поводу усиления контракта в интерфейсе.

Но перед этим меня заинтересовал другой камент участника по поводу языков в которых нельзя создать неинициализированный указатель.

Дайте мне время подумать и я опишу этот поинт.

mikron,

Я читал твой ответ. Щас неудобно. Тайпаю с телефона. Отпишу вечером.

Petro123Диезно такое решение крайне кривое по многим причинам.смотрим причины:

ДиезПредставьте себе ЯП, в котором вообще нет null.
А такой есть?
Больше нет причин?
Интересно рассмотреть вопрос с разных сторон и со стороны разных парадигм и ЯП.

Lisp. В Лиспе Nil (null) имеет очень интересную семантику.

1. Он эквивалентен пустому списку. В примере второй и третий элемент равны по смыслу. Это также очень
тесно связано с внутренними структурами памяти. Память - бинарное дерево и пустой список и Nil это физические
указатели на определенную константу. Но "мыслимые" нами и транслятором как одно и тоже.




2. В булевом контексте Nil рассматривается как false.




О существовании NPE в Lisp я ничего не знаю. Возможно там есть какие-то классы ошибок связанные с разыменованием.
Если кто знает - прошу в топике поделится.

2. SQL. . Я много лет использую SQL. Но не общий диалект а Оракловый. Но здесь тоже есть некоторые наблюдения.

Oracle SQL постулирует определённую алгебру строк в которой пустая строка равна NULL. Это сделано давно из соображений
экономии памяти сегмента таблиц а также пространства индекса в блоках. В других СУБД - возможно по другому.

SQL (не только оракловый а вообще генерализованный) определяет семантику операций сравнения с null. Независимо
от аргументов результат операции сравнения будет равен FALSE (Undefined) если хотя-бы один из аргументов слева
или справа равен NULL. Забавен также факт что NULL не равен сам себе. NULL не участвует в операциях аналитики
и агрегации. Тоесть расчет AVG(field) будет просто скипать поля которые равны NULL.

Подытоживая эти два пункта я хочу сказать. Что в этих парадигмах программирования NULL вообще не является
проблемой разработки. Он скорее по другому определяет операции над Null значениями.

Null - не проблема. Проблема - семантика операций.

В классических ЯП семейства Java/C++/C# любая попытка разыменования типизированной Null-переменной вызовет
немедленную реакцию прерывания основного потока с выбросом различного рода исключений. В С++ может быть
разное поведение. Как говорится depends on.

mikronЯ считаю что это не проблема. Программисты совершают ошибки - они такие же люди.
Не будет NPE будут другие совершать. Поинт в том что Optinal не уменьшат риск появления ошибки.
Более того, программист может с таким же успехом совершить ошибку и вернуть null там где ожидается Optinal.
И если я пишу отказоустойчивый метод, то теперь к прверке на null добавится ешё isPresent.

Это интересный поинт. Я-бы его рассмотрел с разных сторон. Но в первую очередь я как человек дотошный
начал-бы с основ. Давай посмотрим что такое вообще Optional и что о нем пишет сайт производителя.

Я буду читать здесь. С вашего позволения я возьму просто последнюю версию (да щас это уже можно)
JDK API, в разделе Optional.

https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/util/Optional.html

Цитата. Насколько мне позволяет мой слабый intermediate я дам творческий перевод. Если я где-то ошибся - можете дополнить.

public final class Optional<T> extends Object

Контейнер объекта который МОЖЕТ или НЕ-МОЖЕТ содержать не нулевое значение. Если значение есть - isPresent() вернет true. Если значения нет - объект рассматривается как пустой и isPresent() вернет false.

Дополнительные методы которые зависят от наличия или отсутствия значения предоставляются как orElse() (возвращает
дефолтное значение если основное значение отсутствует) и ifPresent ... и т д.

Это - value-based class, использование identity-sensitive операций (включая сравнение ссылок (==), сравнение хеш-кодов, и синхронизацию) на экземплярах Optional может иметь непредсказуемые резульатты и их следует избегать.

API Note:
Optional изначально введен для использования как метод возвращающий тип где четко нужно представить "отсутствие результата"
и где использование null, чрезвато возникновением ошибок. Переменная чей тип Optional, никогда не должна быть нулевой; у нас
всегда есть опциональный экземляр.

mikronЯ таки не понял в чём разница между null и optional. Так уж сложилось что null обозначает - обьекта нету.
Какое тайное знание передаёт мне Optional? Если оставить проповеди Java - веруюших - никакого.
Безполезное и даже вредное дополнение к яве и главниое - ничего не меняет.
А String! - даёт гарантию. Это не условность, и не апель к карзаботчику. Жосткий факт.
В результате код надёжнее, производителнее, компакнее. И время разработки умешается.
Реально сохраняет время/нервы/деньги владельцев софта.

Я думаю что польза или вред от Optional определяется практикой. В нашем случае - практикой защиты от NPE.
,Из таких практик я лично использовал.

1. Модульный тесты . Нудно. Скучно. За это неплатят. Я не всегда придерживаюст 100% покрытия (а у вас сколько только честно?).
В некоторых случаях (перед рефакторингом) я делал тест закрепления. Я специально толкал null везде где только
можно в модульных тестах в публичные методы и закреплял их через такие себе странные утверждения




2. Аннотации семейства jsr305. @Nulllable/@Nonnull Их понимает IDE и SonarQube. И если где-то есть нарушение контракта
на фазе статик-анализа кода то сонар или среда выкинет красный флажок. Это мой любимый метод закрепления
гарантий по NPE.

У них есть братья близнецы в пакетах sun и много еще где.

3. Фабричные методы. Лет 5 назад у нас были серъезные проблемы с биллингом для одного моб-провайдера.
Приложение Java/GWT. UI регулярно сыпался. Причем ловля NPE в GWT старых версий была настоящим мучением.
Обфускация и прочее. Мы достигли внутри группы опеределённх соглашений. Мы вообще отказались от конструкторов
для бизнес энтитей. Мы заменили их 100% на фабричные методы. Методы фабриковали нам объекты с полями
которые были инициализированы специальными магическими констатнами. Строки - "". Даты - дефолтная дата типа 0001 год
от Рождеста Христова. И если это обёртка числового типа - то соотв 0.0. Мы рассудили таким образом. Что левая
констана в UI не приносит столько демеджа сколько NPE. Это было согласовано и заэстимировано и реализовано.
Мы побороли 99% NPE. Дальнейшие фиксы были уже минорчиками. Кастомер был доволен.

4. EMPTY_LIST, EMPTY_MAP e.t.c. Это религия. Мы принципиально отказались от возврата NULL как признака
пустой коллекции. Забано. Но после этого код содержащий for(..) стал проще. Негативных эффектов не было.

Optional мы тогда (Java 1.6) не использовали. Возможно сейчась оглядываясь на 3-й пункт я-бы об этом подумал.
Те практики что мы использовали не были идеальны.

Petro123У меня соседний проект на шарпе. Вроде у них такой метод:
- всегда простые переменные не могут быть null пока не поставишь знак вопроса.
int i? = null разрешено.
Без вопросика запрещено.
Вроде изящное решение.
По умолчанию нигде не будет null )))
Imho
Мда. Я тоже слышал об этом. Дотнетчики пошли по пути изменения синтаксиса языка в угоду некоторым задачам разработки.

Насколько глубока эта проверка? Это фаза компилляции? Или рантайм?

Андрей Панфилов, а меня еще интересует такой вопрос. Есть два DAO.
Один - декларирует безопасный способ возврата значения. Второй - классический.
Кто ответственен за отсутствие NPE в первом случае. В большей степени - автор
реализации SafeDao, или программист который это Dao использует.

Тоесть я хочу понять на чьей стороне будет мяч.

mikronmaytonНасколько глубока эта проверка? Это фаза компилляции? Или рантайм?
Компиляции. Но оставим C#, Optional проблема явы.
Ну ты хитер!

Всех взбаламутил. Втащил в тему обсуждение c#.
Рекомендовал синтаксис уровня компилляции.

А тепер говоришь - оставим!

Ну баламууут!