Исключает ли Null Pointer исключение кода?

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

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

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

Да, RuntimeException любого RuntimeException почти всегда является запахом кода. Кажется, что согласен C2 Wiki .

Исключением, вероятно, были бы некоторые особо защитные fragmentы кода, которые запускали бы довольно случайный код из других модhive. Примерами таких защитных структур могут служить EDT , ThreadPools / Executors и плагиновая система.

Я могу думать о том, чтобы использовать одно приложение для NullPointerException :

 catch (NullPointerException) { ApplyPainfulElectricShockToProgrammer(); } 

Иногда мне приходилось ловить исключение nullpointer из-за ошибки в библиотеке третьей части. Библиотека, которую мы использовали, выбрала это исключение, и мы ничего не могли с этим поделать.

В этом случае нормально его поймать, иначе нет.

Это зависит.

Насколько опытен этот сотрудник? Он делает это для невежества / лености или есть ли для этого веская причина? (например, это главный stream над всем остальным и никогда не должен умирать?)

90% времени, занимающих исключение во время выполнения, ошибочно, 99% ловушки NullPointerException ошибочны (если причина в том, что «я получаю много их …», тогда весь программист ошибается, и вам следует взглянуть на остаток кода, который он делает)

Но при некоторых обстоятельствах использование NullPointerException может быть приемлемым.

В общем, я думаю, что это запах кода; мне кажется, что защитные проверки лучше. Я бы расширил это, чтобы охватить большинство исключенных исключений, за исключением циклов событий и т. Д., Которые хотят уловить все ошибки для отчетов / протоколирования.

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

Веселая

Я просто нашел что-то, что нельзя делать на работе:

 public static boolean isValidDate(final String stringDateValue) { String exp = "^[0-9]{2}/[0-9]{2}/[0-9]{4}$"; boolean isValid = false; try { if (Pattern.matches(exp, stringDateValue)) { String[] dateArray = stringDateValue.split("/"); if (dateArray.length == 3) { GregorianCalendar gregorianCalendar = new GregorianCalendar(); int annee = new Integer(dateArray[2]).intValue(); int mois = new Integer(dateArray[1]).intValue(); int jour = new Integer(dateArray[0]).intValue(); gregorianCalendar = new GregorianCalendar(annee, mois - 1, jour); gregorianCalendar.setLenient(false); gregorianCalendar.get(GregorianCalendar.YEAR); gregorianCalendar.get(GregorianCalendar.MONTH); gregorianCalendar.get(GregorianCalendar.DAY_OF_MONTH); isValid = true; } } } catch (Exception e) { isValid = false; } return isValid; } 

Бааад 🙂

Разработчик хотел, чтобы в календаре делались исключения такого рода:

 java.lang.IllegalArgumentException: DAY_OF_MONTH at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2316) at java.util.Calendar.updateTime(Calendar.java:2260) at java.util.Calendar.complete(Calendar.java:1305) at java.util.Calendar.get(Calendar.java:1088) 

аннулировать значения …

Да, это работает, но это не очень хорошая практика …

Выдача исключения (особенно заполнение трассировки стека) стоит намного больше, чем просто проверка данных вручную без исключения …

Это плохо, но он может создать оптимизированный байт-код.

Если Integer i не имеет null большую часть времени, тогда проверка уменьшает общую производительность. Сам чек стоит 3 инструкции (0-4). Тогда весь случай принимает 7 инструкций (0-14).

 public class IfNotNull { public Integer i; public String getIAsString() { if (i != null) { return i.toString(); } else { return ""; } } } public java.lang.String getIAsString(); Code: 0: aload_0 1: getfield #2 // Field i:Ljava/lang/Integer; 4: ifnull 15 7: aload_0 8: getfield #2 // Field i:Ljava/lang/Integer; 11: invokevirtual #3 // Method java/lang/Integer.toString:()Ljava/lang/String; 14: areturn // <- here we go 15: ldc #4 // String 17: areturn 

Следуя подходу EAFP, который распространен в мире Python. null случай будет дорогостоящим, но нам нужно всего 4 инструкции (0-7) для not null случая.

 public class TryCatch { public Integer i; public String getIAsString() { try { return i.toString(); } catch (NullPointerException npe) { return ""; } } } public java.lang.String getIAsString(); Code: 0: aload_0 1: getfield #2 // Field i:Ljava/lang/Integer; 4: invokevirtual #3 // Method java/lang/Integer.toString:()Ljava/lang/String; 7: areturn // <- here we go 8: astore_1 9: ldc #5 // String a 11: areturn Exception table: from to target type 0 7 8 Class java/lang/NullPointerException 

Кто знает, может ли JIT-компилятор оптимизировать это?

Это определенно.

В большинстве случаев ваши переменные не должны иметь значение null. Многие новые языки выходят со встроенной поддержкой непустых ссылочных типов, то есть типов, которые никогда не будут иметь значение null.

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

Оператор if принимает, возможно, три инструкции для выполнения и является локальной проверкой (что означает, что вы делаете чек в том же месте, в котором вам нужна гарантия).

С другой стороны, с помощью исключения может потребоваться еще много инструкций – система пытается найти метод, не работает, просматривает таблицу исключений для соответствующего обработчика исключений, перескакивает туда, выполняет обработчик и снова переходит. Кроме того, проверка потенциально нелокальная. Если ваш код выглядит примерно так:

 try return contacts.find("Mom").getEmail() catch (NullPointerException e) return null 

Вы не знаете, был ли NPE брошен в «getEmail» или «найти».

Технически худшее решение для очень, очень распространенного шаблона, написанного более запутанным образом? Это не ранг, но он определенно плохо пахнет: /

Единственное место, где вы должны поймать исключение NullPointerException (или, в частности, только любое Throwable), находится на некоторой границе верхнего уровня или системы, чтобы ваша программа не полностью разрушалась и могла восстанавливаться. Например, настройка страницы с ошибкой в ​​вашем web.xml обеспечивает уловку, чтобы веб-приложение могло восстанавливаться из исключения и уведомлять пользователя.

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

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

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

Икс

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

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

Как насчет этого:

 try { foo.x = bar; } catch (NullPointerException e) { // do whatever needs to be done } 

как микро-оптимизация, когда foo может быть нулевым, но почти никогда не существует?

Идея такова:

  • Явная проверка NULL принимает единую машинную инструкцию

  • С другой стороны, проверка NULL во второй версии может быть выполнена, разрешив доступ к NULL, поймав SIGSEGV и выбросив исключение NullPointerException. Это бесплатно, если объект не равен NULL.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Булевы, условные операторы и автобоксинг
  • getActionBar () возвращает Null (AppCompat-v7 21)
  • Почему String.valueOf (null) вызывает исключение NullPointerException?
  • Загрузите листок данных Excel в базу данных Oracle
  • java.lang.NullPointerException: попытка вызвать виртуальный метод для ссылки на нулевой объект
  • java.lang.RuntimeException: Ошибка предоставления результата ResultInfo {who = null, request = 1888, result = 0, data = null} для активности
  • Почему при вызове (статического) метода в нулевой ссылке не выбрасывается исключение NullPointerException?
  • Избегание! = Null
  • Ошибка вызывает виртуальный метод 'double android.location.Location.getLatitude ()' в ссылке на нулевой объект
  • Почему сравнение Integer с int может вызывать NullPointerException в Java?
  • Почему int num = Integer.getInteger («123») бросает NullPointerException?
  • Давайте будем гением компьютера.