По прошествии лет можно констатировать что эксперимент с 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