Почему я получаю исключение NullPointerException при проверке на ненулевые значения?

Question

У меня есть этот конструктор:

public class SentinelT<T> extends NodeT<T> { 

    //constructs an empty Sentinel linked to no other Nodes 
    public SentinelT() { 
     super(null, null, null); 
    this.prev = this; 
    this.next = this; 
    } 
... 
} 

Поэтому, когда я пытаюсь изменить значение this.prev или this.next, или я пытаюсь использовать логические операторы этих значений, я получаю NullPointerException. Например:

public boolean isEmpty() { 
    return this.prev == this && this.next == this; 
} 

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

* Edit: добавлена ​​NODET конструктор, собирается добавить экземпляра, генерирующий исключение

//NodeT class for a doubly linked list of T 
public class NodeT<T> { 
    T data; 
    NodeT<T> prev; 
    NodeT<T> next; 

    //constructs a Node object 
    public NodeT(T data, NodeT<T> prev, NodeT<T> next) { 
    this.data = data; 
    this.prev = prev; 
    this.next = next; 
    } 

* edit2: другой класс, предположим, что stringHeader является полем класса, что это происходит в SentinelT stringHeader = новый SentinelT();

public void testIsEmpty(Tester t) { 
    initData(); 

    t.checkExpect(stringHeader.isEmpty(), true); 
} 

Answer 1

Это трудно для меня, чтобы сказать наверняка, что это неправильно, не видя больше кода, но вы говорите, что вы получаете «NullPointerException» при проверке против ненулевых значений. Вы использовали отладчик и поставили точку останова в isEmpty и доказали, что во время выполнения isEmpty, что this.prev и this.next не равны нулю? Я бы настоятельно предложил использовать точки останова, чтобы проверить ваши предположения о значениях этих членов данных.

EDIT - после просмотра вашего редактирования: Это яркий пример того, почему вы должны показывать больше кода, чем там, где вы указываете свою ошибку. В истории часто бывает больше. Отладчики - лучший друг кодера. Проверьте свои предположения в отладчике.

Answer 2

Ну, this не может быть null когда-либо. Поэтому либо prev, либо next должно быть null. Ваш конструктор назначает this как prev, так и next, так что это не может быть причиной того, что один из них - null. Следовательно, должен быть другой код, который вы не показываете, который устанавливает один (или оба) из них на null.

EDIT

На второй мысли, просто потому, что значение null, не означает, что он будет бросать NPE здесь.

ВТОРОЙ EDIT

С testIsEmpty кода раскрывается, то либо t или stringHeader должны быть null.

Answer 3

Единственный способ, которым я могу видеть, как это происходит, если stringHeader или t является null ...

(реквизиты jlordo для t) ...

Answer 4

Давайте быть ясно об этом:

public boolean isEmpty() { 
    return this.prev == this && this.next == this; 
} 

Этот метод НЕ МОЖЕТ бросать NullPointerException.Ни одна из операций она не выполняет может выбросить никаких исключений:

• this не может быть null так, this.prev и this.next не может бросили NPE
• Использование == сравнить ссылку с null (или любой другой ссылки) не может бросить NPE.

Итак, если вы получаете NPE, он идет откуда-то еще ... и вы неправильно интерпретируете трассировку стека.

---

Второй пример:

t.checkExpect(stringHeader.isEmpty(), true); 

В этом примере есть несколько способов, что NPE может быть брошенными.

• Если stringHeader является null то stringHeader.isEmpty() выбросит NPE.
• Если t - null, то NPE будет выброшен вызовом t.checkExpect.

Также можно (теоретически), что NPE может быть выброшен в пределах checkExpect или isEmpty звонков, но StackTrace бы предоставить доказательство, что это произошло.

---

Уроки извлечь из этого:

• Прочитайте трассировку стека тщательно, и научиться правильно интерпретировать.
• Прочтите код, который вы написали. Прочтите внимательно.
• Убедитесь, что вы понимаете, что могут быть конструкты Java, и что не может выбросить NPE ... или другие внутренние исключения. (В некоторых случаях есть некоторые тонкости ... хотя и не здесь.)
• Не переходите к выводам, которые не подтверждены доказательствами. «Потому что вы, вероятно, тратите много времени, делая это ... если ваш« вывод »окажется неправильным.
• Если вы не можете понять это, обратите внимание на дополнительные доказательства:
  • Используйте отладчик, чтобы установить точки останова, рассмотрит переменные, один шаг кода, и так далее
  • Добавить регистрацию или (временные) следовые отпечатки.
  • «Рука выполнить» в вашей голове или на бумаге.
• Если вы просите кого-нибудь на помощь, они должны видеть ВСЕ соответствующие код трассировки стека и другие доказательства, так что они могут урезонить его через себя. Если вы просто предоставите свою (возможно, неверную) интерпретацию доказательств, вы не получите полезной помощи.
• Не предполагайте, что проблема находится в чьем-то коде: «Возможно, это проблема с пакетом тестера, который использует мой профессор?» .... WRONG!