java comparable null_Java：檢查Comparable是否為null返回NullPointerException

I have a big problem with this code and I have no idea how to cause it:

我對這段代碼有一個很大的問題,我不知道如何導致它:

while(tree.find(indexreg)!=null){

//do stuff

}

For some reason, comparing tree.find(indexreg) with null causes a NullPointerException. Since this is a college project I have to use my own binary tree implementation instead of the one provided by Java. tree is a BinarySearchTree and indexreg is a Comparable object, that was already initialized. This is the code for find in the BinarySearchTree class:

出於某種原因,將tree.find(indexreg)與null進行比較會導致NullPointerException。由於這是一個大學項目,我必須使用自己的二叉樹實現而不是Java提供的實現。 tree是BinarySearchTree,indexreg是一個已經初始化的Comparable對象。這是BinarySearchTree類中的find代碼:

public Comparable find(Comparable x) {

return elementAt(find(x, root));

}

It looks for the object in the tree and it returns null if it doesn't find it (I don't think you can return an empty Comparable object). I tried Googling but I didn't find an useful answer. Does anyone know how to make this code work?

它在樹中查找對象,如果找不到它則返回null(我認為你不能返回一個空的Comparable對象)。我嘗試使用谷歌搜索,但我找不到有用的答案。有誰知道如何使這個代碼工作?

3 个解决方案

#1

2

I don't think the problem has anything to do with your Comparable.

我不認為這個問題與您的Comparable有關。

If the line while(tree.find(indexreg) != null) { throws a NullPointerException, it must be because tree is null. No other possibilities are credible.

如果行while(tree.find(indexreg)!= null){拋出NullPointerException,則必須是因為tree為null。沒有其他可能性是可信的。

Comparison of an object reference with null using == or != will NOT throw an NPE. So even if tree.find(...) returned a null, that can't be the cause of this exception.

使用==或!=將對象引用與null進行比較將不會拋出NPE。因此,即使tree.find(...)返回null,也不能導致此異常。

Passing a null value as a method argument will NOT throw an NPE. So if indexreg was null, that wouldn't cause this exception. (An NPE could be thrown by the find method or something it calls, but the stacktrace will not show a different line in a different method as the origin of the exception.)

將null值作為方法參數傳遞將不會拋出NPE。因此,如果indexreg為null,則不會導致此異常。 (可以通過find方法或它調用的東西拋出NPE,但堆棧跟蹤在不同的方法中不會顯示與異常原點不同的行。)

(I could be misinterpreting the question. I'm assuming that the OP means "throws" when he says that the line "causes" the exception.

(我可能會誤解這個問題。我認為當他說該行“導致”異常時,OP意味着“拋出”。

Unfortunately, the OP is only posting snippets of code and hasn't shown us the stacktrace ... which is the critical piece of evidence.)

不幸的是,OP只發布了代碼片段,並沒有向我們展示堆棧跟蹤......這是關鍵的證據。)

#2

2

public Comparable find(Comparable x) {

return x == null ? null : elementAt(find(x, root));

}

fyi this is equivalent to:

這相當於:

public Comparable find(Comparable x) {

if (x == null) return null;

return elementAt(find(x, root));

}

You nay also consider improving the clarity of your code: You have a method call and a test combined. While this is not "bad" per se, IMHO it would be cleaner to separate the two, AND get a hold of the value returned in case you want to do something with it, like this:

您也可以考慮提高代碼的清晰度:您可以進行方法調用和測試。雖然這本身並不“壞”,但恕我直言將兩者分開會比較清楚,並且如果你想對它做一些事情,請保留返回的值,如下所示:

for (Comparable> result = tree.find(indexreg); result != null; result = tree.find(indexreg)) {

//do stuff with variable "result"

}

It just makes it more obvious what is controlling the loop.

它只是讓控制循環變得更加明顯。

There is another way to get the result, but it's considered "bad coding style" by some; that is to assign and test in one:

還有另一種獲得結果的方法,但有些人認為它是“糟糕的編碼風格”;那就是分配和測試一個:

Comparable> result;

while ((result = tree.find(indexreg)) != null) {

//do stuff with variable "result"

}

Some believe that you should avoid this style of coding. I tend to agree with them.

有些人認為你應該避免這種編碼風格。我傾向於同意他們。

#3

0

Possibly indexreg is null, not initialized at all. You should certainly code find() more defensively as suggested by @Bohemian but this may be the underlying problem. Or see next comment below.

可能indexreg為null,根本沒有初始化。你應該按照@Bohemian的建議更加防御性地編寫find(),但這可能是潛在的問題。或者看下面的下一條評論。