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