Null safety of Kotlin. Мысль про киллер фичу

[Kate]

Познакомившись впервые с языком Котлин после продолжительной работы с Java меня воротило от одной мысли, что null-safety может быть полезен и вообще переменная без null - примитив, но я сам этого не осознавал.
Как это проявлялось:

1. Не удобно работать с переменными и филдами, у которых не может быть null. Ну просто даже не понимал, как что-то не может быть null.
2. Не удобно работать с nullable типами. Ну блин ?: !!

Вообщем шло время, потихоньку начинал привыкать к тому, что null может не существовать, даже пытался сделать что-то на мой тот взгляд идиоматичное: дефолтные значения в виде объекта.... Вообщем все это меня вгоняло в тоску и я очень хотел опять писать на Java, так как привык жить с null. Прошло время я уже нормально начал жить с котлиновским not nullable, как в друг в один прекрасный день я вернулся в Java... И через время осознал одну вещь:
Когда я работаю с легаси кодом (ну это весь код, который вообще пишется), то я не понимаю, где у может быть null, а где нет, что заставляет меня делать переключение контекста от реализации бизнес логики на выяснение: а может ли тут быть null?
Рассмотрим синтетику: У нас есть сущность номер телефона с филдами: номер, международный код города и префикс (ну +7, +3 и т.д.), написана она до нас, есть мэппинг в базу, вообщем все по канонам кровавого. По бизнесу все 3 поля номера телефона обязаны быть.
Если я в Java, то при работе с этой сущностью у меня есть сколько вариантов как ее использовать:

1. Использовать как есть, не думая о том, что там с null-ам (продакшен разберется, если что баг пофиксим)
2. Дойти до базы данных и посмотреть на констрейнт, тем самым убедившись, что null там не может быть и можно спокойно юзать эту сущность без проверок.
3. Если расставлены аннотации @NotNull, нажать Ctrl+Q, чтобы увидеть описание.
4. Обработать все поля, предполагая, что везде может быть null.
5. Написать свой код, потом разобраться с потенциальным null.
6. Можно еще придумать варианты....

Все, кроме первого варианта, заставляют меня приложить усилия на переключение контекста и отвлечься от основной мысли над которой я работаю, ну да пункт 5 может сохранить мое внимание какое-то время, но потом прийдется потратить еще кучу времени на переключение контекста. Первый в принципе не плох, но потом будет весело разбираться с NPE.
Какие у нас есть варианты в Котлин:

1. Значение филда может быть null и я могу сразу обработать такой кейс.
2. Значение не может быть null.

То есть оба варианта не сбивают меня, не заставляют меня переключить свое внимание.
Конечно тут можно возразить, что есть совместимость с Java и там все плохо в этом плане, на что есть такой ответ: совместимость это круто, но как он сделан, это трейд офф, чтобы не плодить море конструкций вида !! ?:
Ну и еще раз про само свойство null safety: это не совсем техническая штука, скорее это про бизнес, если у меня в бизнесе какое-либо значение не может быть null, так пусть оно упадет на ранних этапах, чем с каким-то null жить.


Источник статьи: https://habr.com/ru/post/560634/