Является ли перехват исключений нулевого указателя запахом кода?

Question

Недавно мой коллега написал в некотором коде, чтобы перехватить исключение нулевого указателя вокруг всего метода и вернуть один результат. Я указал, как могло быть любое количество причин для нулевого указателя, поэтому мы изменили его на защитную проверку для одного результата.

Однако перехват NullPointerException мне показался неправильным. На мой взгляд, исключения нулевого указателя являются результатом неправильного кода и не являются ожидаемым исключением в системе.

Есть ли случаи, когда имеет смысл перехватить исключение нулевого указателя?

Answer 1

Захват NPE (фактически любых RTE) может быть необходим для чистого завершения приложения на основе Swing-GUI.

edit: в этом случае это обычно делается через UncaughtExceptionHandler.

Answer 2

Перехват исключения NULL-указателя действительно зависит от контекста ... нужно стремиться избегать строгих абсолютных правил ... правила должны применяться в контексте - хотите перехватить это исключение и перевести все программное обеспечение в некое состояние STABLE - делаем ничего или почти ничего. Все такие правила кодирования должны быть хорошо поняты

В этот момент вы смотрите на свою программу AUDIT TRACE ... что вы должны делать и обнаруживаете ИСТОЧНИК этого исключения.

Идея о том, что исключение NULL Pointer никогда не возникнет, должна быть проверяемой. Сначала проведите статический анализ ... (что сложнее, если поступит сторонний код / ​​компоненты), а затем выполните исчерпывающий поиск в пространстве состояний с использованием соответствующих инструментов.

х

Answer 3

Давно у меня было одно применение. Особенно глупая библиотека выдает исключение NullPointerException при запросе объекта в коллекции по ключу, а объект не найден. Не было другого способа поиска, кроме как по ключу, и нет способа проверить, существует ли объект.

Некоторое время спустя мы загрузили поставщика и начали модифицировать библиотеку. Теперь библиотека генерирует лучшее исключение (мое изменение) и имеет функцию проверки (чужое изменение).

Конечно, я всегда буду иметь ровно одну строку внутри блока try. Больше, и я сам был бы виновен в плохом коде.

Answer 4

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

Поймать любое RuntimeException плохо. Но если это действительно необходимо, то комментарий в коде будет очень полезен для будущих программистов, которые будут работать над этим кодом. Если вы не можете написать разумный комментарий, чтобы поймать их, вы должны избегать их. период.

Answer 5

Да, в Java необходимо проверить исключение NullPointerException.

Брошенный, когда приложение пытается использовать нуль в случае, когда объект требуется. К ним относятся:

Вызов метода экземпляра нулевого объекта. Доступ или изменение поля нулевого объекта. Принимая длину нуля, как если бы это был массив. Доступ или изменение пустых слотов, как если бы это был массив. Бросить ноль, как если бы это было значение Throwable.

Приложения должны генерировать экземпляры этого класса, чтобы указать на другое незаконное использование нулевого объекта.

NullPointerException на других языках при чтении текстовых файлов (например, XML), записи которых не были проверены на правильный символ ASCII и формат записи.

Answer 6

Это действительно зависит от определения интерфейса.Неструктурированная обработка NPE так же плоха, как и перехват Exception или Throwable.

Нули полезны для идентификации неинициализированного состояния, вместо использования пустой строки или max_int или чего-либо еще.Однажды место, где я регулярно использую ноль, находится в местах, где объект обратного вызова не имеет отношения.

Мне действительно нравится аннотация @Nullable, предоставленная Guice.

http://code.google.com/docreader/#p=google-guice&s=google-guice&t=UseNullable

Чтобы исключить исключения NullPointerException в вашей кодовой базе, вы должны быть дисциплинированными относительно нулевых ссылок.Мы добились успеха в этом, следуя и применяя простое правило:

Каждый параметр не равен нулю, если не указано явно.Библиотека Google Collections и JSR-305 имеют простые API-интерфейсы для контроля нулей.Preconditions.checkNotNull может использоваться для быстрого сбоя, если найдена нулевая ссылка, а @Nullable может использоваться для аннотирования параметра, который допускает нулевое значение.

Guice по умолчанию запрещает null.Он откажется ввести нуль, если вместо этого произойдет исключение ProvisionException.Если ваш класс допускает null, вы можете аннотировать поле или параметр с помощью @Nullable.Guice распознает любую аннотацию @Nullable, например, edu.umd.cs.findbugs.annotations.Nullable или javax.annotation.Nullable.

Answer 7

Перехват NullPointerException может быть полезен, если ваш метод вызывает внешний интерфейс (или SOAP API) и существует вероятность того, что возвращаемое значение может быть равно Null. Кроме этого, нет ничего особенного в том, чтобы поймать эти исключения.

Answer 8

Я пытаюсь гарантировать результаты от моих интерфейсов, но если какая-то библиотека или код кого-то может выдать нулевой результат в результате, и я ожидаю, что гарантия перехвата будет возможной. Конечно, что вы делаете, как только поймаете, решать только вам. Иногда просто не имеет смысла проверять наличие нуля, и если вы поймаете его, у вас есть какой-то другой метод решения проблемы, который может быть не таким хорошим, но выполняет свою работу.

То, что я говорю, это использовать исключения для того, что вы можете, это довольно хорошая языковая функция.