Как проследить NullPointerException в цепочке методов get

В ИДЕЕ IntelliJ можно установить exceptionbreakpoints. Те точки останова стреляют каждый раз, когда указанное исключение выдается (можно определить объем этого к пакету или классу).

Тот путь должно быть легко найти источник Вашего NPE.

я принял бы, что можно сделать что-то подобное в netbeans или затмении.

РЕДАКТИРОВАНИЕ: Здесь объяснение о том, как добавить exceptionbreakpoint в затмении

NPE является самое бесполезное Исключение в Java, период. Это, кажется, всегда лениво реализуется и никогда не говорит точно, что вызвало его, как раз когда простой как "класс x.y. Z является пустым", помог бы много в отладке таких случаев.

Так или иначе, единственным хорошим способом, которым я нашел для нахождения метателя NPE в этих случаях, является следующий вид рефакторинга:

someObject.getSomething()
          .getSomethingElse()
          .getAnotherThing()
          .getYetAnotherObject()
          .getValue();

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

Я обычно не объединяю методов get в цепочку как это, где существует больше чем один nullable метод get.

, Если Вы работаете в своем язе, можно просто установить точку останова и использовать, "оценивают выражение" функциональность язя на каждом элементе последовательно.

, Но Вы собираетесь быть царапанием Вашей головы момент, Вы получаете это сообщение об ошибке от своих журналов рабочего сервера. Настолько лучше всего сохраните макс. nullable объектом на строку.

Между тем мы можем мечтать о оператор

Если Вы пишете часто:

a.getB().getC().getD().getE();

это - вероятно, запах кода и должно избежаться. Можно осуществить рефакторинг, например, в a.getE(), который звонит b.getE(), который звонит c.getE(), который звонит d.getE(). (Этот пример не может иметь смысла для Вашего конкретного варианта использования, но это - один шаблон для фиксации этого запаха кода.)

Видят также Закон Demeter, который говорит:

• Ваш метод может назвать другие методы в своем классе непосредственно
• , Ваш метод может назвать методы на своих собственных полях непосредственно (но не на полях полей)
• , Когда Ваш метод берет параметры, Ваш метод может назвать методы на тех параметрах непосредственно.
• , Когда Ваш метод создает локальные объекты, тот метод может назвать методы на локальных объектах.

Поэтому не нужно иметь цепочки сообщений, например, a.getB().getC().doSomething(). В соответствии с этим "законом" обладает значительно большим количеством преимуществ кроме создания NullPointerExceptions, легче отладить.

Вот то, как найти ошибку, с помощью Eclipse.

Первый, устанавливает точку останова на строке:

someObject.getSomething().getSomethingElse().
getAnotherThing().getYetAnotherObject().getValue();

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

Теперь, выделите "someObject" и нажмите CTRL+SHIFT+I (или щелкните правой кнопкой и скажите, "осматривают").

действительно ли это является пустым? Вы нашли свой NPE. Действительно ли это является непустым? Тогда выделите someObject.getSomething () (включая круглую скобку) и осмотрите его. Действительно ли это является пустым? И т.д. Продолжите вниз цепочку для выяснения, где NPE происходит, не имея необходимость изменять код.

Ранний отказ является также опцией.

Где угодно в Вашем коде, что нулевое значение может быть возвращено, рассмотрите представление проверки на пустое возвращаемое значение.

public Foo getSomething()
{
  Foo result;
  ...
  if (result == null) {
    throw new IllegalStateException("Something is missing");
  }
  return result;
}

Можно хотеть обратиться к этот вопрос о предотвращении! = пустой указатель .

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

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

, Если у Вас есть метод или конструктор, который берет параметр объекта и рассматриваемый объект/метод, не может разумно иметь дело с тем параметром, являющимся пустым, тогда просто проверить и бросить NullPointerException тут же.

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

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

В затмении (и большинство IDE) можно также использовать отслеживаемые выражения для оценки кода, работающего в отладчике. Вы делаете этот bu выбор кода и используете contet меню для добавления новых часов.

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

Разместите каждого метода get в его собственную строку и отладку. Переступите (F6) через каждый метод для нахождения, какой звонок отвечает пустой указатель