По прошествии лет можно констатировать что эксперимент с checked эксепшенами провалился, и хотя совсем от этого уйти не получается, но многие фреймворки и обычные программисты двигаются в сторону только unchecked exceptions. В крайне редком случае, например как в примере выше и в целом когда есть какая-то разумная возможность обработать эксепшен, то только тогда можно использовать checked. В случае нуллпоинтер, нулевая ссылка - всегда нулевая ссылка, и лучше минимизировать ущерб сразу же остановив программу.

Вообще, стратегия обработки ошибок последовательно шла так:

Возврат кода ошибки или dummy value(-1, NaN и т.д) ===> этот способ имеет следующие недостатки: не всегда найдется корректное dummy значение, ведь -1 может быть правильным значением 2) Так как сигнатура метода никак не описывает возможности ошибки, ее легко можно забыть обработать

Непроверяемые исключения ==> Это был следующий шаг, который позволял делать централизованную обработку ошибок, но все равно сама возможность ошибки никак не декларировалась и нужно было смотреть документацию и тд.

Проверяемые исключения ==> Это был эксперимент Java, насколько я знаю ни в одном другом промышленном языке такой конструкции так и не прижилось. Идея была в том, чтобы закодировать возможность ошибки в самой сигнатуре метода, вы обязаны предпринять какие-то действия(либо пробросить либо обработать), но недостатками было 1) захламление кода, когда метод может состоять из одной строчки полезного кода и 15 эксепшен хандлеры и 2) непредсказуемый флоу выполнения кода, вещь аналогичная goto, если крепко призадуматься.

Умные люди извлекли из этого урок и теперь мейнстримом является описывать возможность ошибок в качестве типа возвращаемого значения, и не только возможность ошибок, а опциоальность, асинхронность и т.д, что по научному называется effects. В данном случае программист всегда видит имеется ли возможность что вызываемый код вернет ошибку и имеет свободу извлечь значение из контейнерного типа или работать с контейнером, а реальное извлечение значение будет где-то наверху(в идеале во входной точке приложения). Таким образом ядро вашего кода остается pure(предсказуемым и без side-effectов), ошибку невозможно пропустить, но ваш флоу не может прерваться и уйти непонятно куда.

Что касается топика, и нуллпоинтеров, нет смысла кодировать такие проверки, а надо использовать тип Optional если есть какие-то возможности отсутствия значения. Если же нуллпоинтер выскакивает в другом месте, то это очевидная ошибка и программу надо прекращать ибо ваши assumptions о том что переменная будет не равна null оказались вдребезги разбиты суровойреальностью, и чтобы не навредить коду выше или ниже, лучше завершить JVM немедленно

chpashaзабыл ника надо использовать тип Optional
стоит заметить, что сфера применения Optional узко ограничена, а NPE может возникнуть где угодно. например при доступе к параметрам метода или приведении типа

1) Приведение типов - зло.
2) Почему параметр не Optional?

Ну я про то и говорю, что когда есь разумные предпосылки того что объекта может и небыть и есть какой-то способ обойти это - тогда используем Optional, в других случаях даем JVM спокойно умереть от NPE

Leonid Kudryavtsevзабыл ник....даем JVM спокойно умереть от NPE
Как-то круто.

А если JVM это WebLogic с 100500 корпоративных пользователей и не законченными транзакциями, тоже даем "спокойно умереть от NPE" ?

Конечно, а какие варианты? Ну уточню конечно что под JVM я подразумевал программу\runnable\песочницу\реквест к сервлету\контейнер и т.д. Если JVM просто хостит контейнеры, ив контейнеры произошел NPE то надо убивать только его, я думал это очевидно

Basil A. SidorovЕсли убивать(ся) по каждому NPE - не напасётесь даже контейнеров.

Какие альтернативы? Еще раз поясню мысль:
1) Мы в сервлете, делаем что-то, натыкаемся на нулевой референс - прекращаем обработку реквеста ибо ничего путного не получится и сэкономим ресурсы БД
2) Мы в потоке\Runnable\Spark job натыкаемся на нулевой референс, что еще можно сделать кроме как закенселиться?
3) Десктопное приложение при инициализации - словили нуллпоинтер - убили JVM

В нормально написанном коде нуллпоинтеров быть не может, точка. Если есть возможность того что объекта может не быть - юзаешь Optional или фильтруешь инпут до гарантированного состояния, в любом другом случае - креш таска и фикс нуллпоинтера, никаких retry или handle

TsyklopandreykaTюзай скалу
спасибо, но нет.
Возможно зря, потому что
Где-то в степизабыл ник,
даже иногда бывает что из релиза приходится вытаскивать этих мондавошек,будь они неладные ))
После перехода на скалу 2 года назад, видел нуллпоинтер раза 3, все из javaбиблиотек прилетали.

П.С. Не пропагандирую скалу, там есть много моментов, но изучить крайне советую для расширения программистского сознания

Petro123andreykaTюзай скалусбегать от NPE в программировании это все равно что проводнику поезда жаловаться на стук колес.
Это атрибут жизни. Побочный продукт создания программы.
Какие к черту колеса у чемодана? Это ж его носить неудобно будет

Basil A. SidorovИ NullPointerException и, например, NumberFormatException - суть одно и то же: некорректные данные.

Оо От кого-кого, а от вас я такой чуши услышать не ожидал. Именно потому что его можно обработать, NumberFormatException и является проверяемым. По вашей логике тогда и NPE должен таким быть. Не говоря о том, что сравнить нуллпоинтер с невалидными данными, это как просить айтишника починить компьютер, ну ты ж все равно с ними там работаешь...(с)

Basil A. SidorovПри этом, чтобы определить null достаточно сделать простое сравнение,
Поэтому я и говорю, что вся валидация входных данных происходит на первом шаге программы, после которого все инварианты домен модели провалидированы и гарантировано верны. Если доменная модель предполагает отсутсвие некого значения - оно кодируется как optional. После этого запускается бизнес-логика(проверка на null ,к слову, врядли ею является, программисты часто путают с нею детали имплементации), которая в идеале без side-эффектов, при одинаковом input должны получаться одинаковые и предсказуемые output. И какие тут null могут быть? В таком случае только убивать(ладно, ладно не JVM, а текущий поток, уговорили) ибо инвариант программы нарушен. точка. Лови-свищи потом причину этого NPE.

Basil A. SidorovПадать каждый раз, когда у вас оказались некорректные данные - глупо.

Конечно, лучше вернуть некорректный результат.
Basil A. SidorovВ результате, в некоторых случаях, RuntimeException можно просто подавить (запротоколировать), сохранив корректность поведения.

Ну равняться на говнокод идея не очень здравая. А JAVA API-делы ребята не устают обсираться раз за разом, достаточно вспомнить первые дизайны collection и datetime api.

Basil A. SidorovP.S.
Напомню, для полноты картины, что Exception тоже не контролируются, но уже по другим причинам.
Это-то тут к чему? Подтвердить авторитетность мнения ссылкой надеясь что никто не будет разбираться?

P.S.
Я прекрасно понимаю многие ограничения, которые накладываются Java(во многом из-за прежних ошибок и нежеланием исправить дело из-за маниакального желания сохранять обратную совместимость) на всю идеальную картину, описанную выше, и optional там убогое кастрированное говно, но это не повод упираться и говорить что "все так должно быть", потому что мы годами так пишем и по-другому непанимаим. Если бы все следовали такой точке зрения то ни лямбд, ни стримов ни паттерн-матчинга мы бы так и не дождались. так что NPE в коде это никак не может быть частью НОРМАЛЬНО написанной программы.

andreykaTполагаю что явно хэндлить нпе надо только там где ты явно их ожидаешь.
Это в каких случаях, например? Можно из реального проекта? Если не изменяет память catch(NullPointerException) многими тулами статик-анализа подсвечивается как ошибка. Ну и этот код никогда в жизни не прошел бы код-ревью в нормальной конторе.
andreykaTкстати.. по скале.. сейчас кинули на скаловский проект. мне показалось что там тоже излишне этому придают внимание и всё суть слилось к тому что если у тебя может быть дырка вместо значения просто юзай опшн и всё. правда, потом появляется барахло навроде тут вот мы думали что дырок быть не может а теперь оказывается может и переписываешь как ишак всё на опшены.
Можно опять же пример? Вся красота скалы в for-comprehension, что есть синтаксический сахар над монадами. Когда ты входишь в optional контекст и далее работаешь с чистыми и валидными данными, а их отсутствие проверяется и хэндлится без вашего участия. Использовать optional вне контекста монад мало чем отличается от java-way. Собственно, поэтому optional так туго в java и прижился - потому что приходится таскать его туда-сюда через иерархии вызовов и захламлять код проверками на isDefined и прочей херотой.

andreykaTну например, ты читаешь сущность с базы где есть поля (у сущности и у базы), которые могут быть налл. очевидно, что все дальнейшие эволюции с этой сущностью ты будешь проводить подозревая, что там может быть и пусто.
Почему они не обозначены в энтити как Optional?
Подозреваю, что правильный ответ - так проще и меньше печатать, и сигнатуру функций красивее, ну так чему удивляться? Система типов для того и создана чтобы облегчать нам жизнь, и если какую-то проверку можно перенести в тип - то надо так и делать, иначе вам в javascript

andreykaTчто значит без твоего участия хендлится? если ты имеешь ввиду операции внутри маппинга и никогда не вынимать чистое значение, ну так имхо, это тоже самое как предположение что у нас типа всё окей и типа работаем будто всё есть и пихаем туда 100500 операций или 100500 последовательных маппингов. но в любом случае ты это оконечишь орелсом. ну или как есть его передашь там куда-нибудь дальше где оно всё-равно уже без твоего участия сделает тоже самое.
Ну да, во входной точке приложения у тебя будет




И что в этом плохоо? Если это в одном месте, прямо у входа?
Вся идея как раз в том, чтобы поместить в контекст и не доставать чистое значение, только на самом верху. А все остальное - чистая функция без сайд-эффектов. Предсказуемая и повторяемая. Геморрой начинается когда у тебя два контекста(например Option + Future или Either + Option и т.д), тогда да - в скале приходится пичать тучу кода, но ведь можно взять scalaz или cats