Маскировка NullPointerException даст очередной бред разработчикам, так как их засыпает логикой, которую мы позволяем Object указывать в памяти на null значение. Если мы поймаем NullPointerException , мы снова поймаем ошибочный код, который принимает значение null. В идеале мы должны запретить объекту принимать нулевое входное значение в коде и быть допустимым кодом. Я видел, как null передается в качестве параметров в один из объектов, созданных в коде, и код успешно приводит пользователя к выполнению действий. Как это возможно. Рискованно ли реализовывать такую реализацию, которая противоречит нормам NullPointerException? В качестве запасного варианта мы даже не можем использовать RuntimeException, так как это замаскирует NullPointerException от возникновения, и мы не узнаем, что код с ошибками изначально был ошибкой?
Перехват исключения нулевого разыменования обычно является плохой идеей независимо от платформы/языка. Если ваш код допускает значение null для какого-либо параметра, обработайте его явно. В противном случае, за исключением некоторых глючных библиотек и т. д., просто не делайте этого. Однако не удается найти окончательную ссылку на Java (quora.com/…).




Поскольку у вас есть тег для Spring, я поделюсь примером. Он использует Springboot и Hibernate Validator, но только для информации об одном из способов обработки этого случая.
http://www.springboottutorial.com/spring-boot-validation-for-rest-services
Привет. Я новичок на этом сайте. Могу я узнать, почему за это проголосовали. Как объяснено в моем ответе, это было опубликовано только для информации в качестве одного примера того, в какой момент обрабатывался нуль, а не фактический ответ.
Это слишком широко, чтобы ответить в целом. Но, как правило, они являются результатом отсутствия проверки пользовательского ввода или ошибок кодирования.