我应该将初始 java String 值从 null 设置为“”吗?
我经常有一个这样的类:
public class Foo
{
private String field1;
private String field2;
// etc etc etc
}
这使得 field1 和 field2 的初始值等于 null。 让我的所有 String 类字段如下所示会更好吗?
public class Foo
{
private String field1 = "";
private String field2 = "";
// etc etc etc
}
然后,如果我与类定义保持一致,我就可以避免很多空指针问题。 这种方法有什么问题?
Often I have a class as such:
public class Foo
{
private String field1;
private String field2;
// etc etc etc
}
This makes the initial values of field1 and field2 equal to null. Would it be better to have all my String class fields as follows?
public class Foo
{
private String field1 = "";
private String field2 = "";
// etc etc etc
}
Then, if I'm consistent with class definition I'd avoid a lot of null pointer problems. What are the problems with this approach?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(11)
绝对不。 空字符串和空字符串是完全不同的东西,您不应该混淆它们。
进一步解释:
这个变量,或者它没有值”
正如 Yuliy 已经提到的,如果你看到很多空指针异常,那是因为你期望事情发生在没有值的情况下却有值,或者在使用事物之前对它们进行初始化很草率。无论哪种情况,您都应该花时间正确编程 - 确保应该具有值的事物具有这些值,并确保如果您正在访问可能没有价值的事物的价值,请考虑到这一点。
Absolutely not. An empty string and a null string are entirely different things and you should not confuse them.
To explain further:
this variable, or it has no value"
As Yuliy already mentioned, if you're seeing a lot of null pointer exceptions, it's because you are expecting things to have values when they don't, or you're being sloppy about initializing things before you use them. In either case, you should take the time to program properly - make sure things that should have values have those values, and make sure that if you're accessing the values of things that might not have value, that you take that into account.
那就是疯狂(通常)。 如果您遇到很多空指针问题,那是因为您在实际填充它们之前尝试使用它们。 这些空指针问题就像响亮而令人讨厌的警报声,告诉您该用途在哪里,然后您就可以进去解决问题。 如果您最初将它们设置为空,那么您将面临使用它们而不是您实际期望的风险。
That way lies madness (usually). If you're running into a lot of null pointer problems, that's because you're trying to use them before actually populating them. Those null pointer problems are loud obnoxious warning sirens telling you where that use is, allowing you to then go in and fix the problem. If you just initially set them to empty, then you'll be risking using them instead of what you were actually expecting there.
我认为当你使用 String s = null 时,它只会在堆栈上创建变量“s”,并且堆上不会存在任何对象,但是一旦你声明了类似 String s=""; 的东西。 它所做的就是在堆上创建“”对象。正如我们所知,字符串是不可变的,因此每当您每次为字符串变量分配新值时,它都会在堆上创建新对象...所以我认为 String s=null比 String s = ""; 高效
欢迎提出建议!!!!
I think when you use String s = null it will create variable "s" on stack only and no object will exists on heap,but as soon as you declare things as like String s=""; what it will does is like it will create "" object on heap.As we know that Strings are immutable so whenever u wil assign new value to string varible everytime it will create new Object on heap...So I think String s=null is efficient than String s = "";
Suggestions are welcome!!!!!
Null 更好,这就是为什么它们被称为未经检查的异常{空指针异常}。 当抛出异常时,它告诉您必须在调用它的任何方法之前将其初始化为某个非空值。
如果你这样做
private String field1 = "";
您正试图抑制该错误。 以后很难发现这个bug了。
Null is better, that is why they are called unchecked exceptions {Null pointer exception}. When the exception is thrown, it tells you that you have to initialize it to some non null value before calling any methods on it.
If you do
private String field1 = "";
You are trying to supress the error. It is hard to find the bug, later.
我会避免这样做,您需要知道您的实例是否没有正确填充数据。
I would avoid doing this, you need to know if your instances aren't getting populated with data correctly.
我不建议。
相反,您应该为您的字段提供合理的值。 如果他们不需要改变,我会把他们定为最终的。
无需分配,我尚未初始化值。 只需给它初始值即可。
I would suggest neither.
Instead you should give your fields sensible values. If they don't have to change, I would make them final.
No need to assign, i'm-not-initialised-yet values. Just give it the initial values.
我知道这是一个老问题,但我想指出以下几点:
显然
,真正的答案是应该使用 StringBuffer 而不是仅仅连接字符串,但我们都知道,对于某些代码来说,连接起来更简单。
I know this is an old question but I wanted to point out the following:
whereas
obviously the really answer to this is that one should use StringBuffer rather than just concatenate strings but as we all know that for some code it is just simpler to concatenate.
一般来说,最好避免这种情况。 有几个原因:
获取 NullPointerException 通常是一个很好的警告,表明您在应该使用的变量之前使用了变量,或者您忘记设置它。 将其设置为空字符串将消除 NullPointerException,但可能会在程序中进一步导致不同的(且更难以追踪)错误。
null 和“”之间可能存在有效差异。 空值通常表示未设置任何值或该值未知。 空字符串表示它被故意设置为空。 根据您的程序,这种细微的差异可能很重要。
Generally it would be best to avoid this. A couple of reasons:
Getting a NullPointerException is generally a good warning that you are using a variable before you should be, or that you forgot to set it. Setting it to an empty string would get rid of the NullPointerException, but would likely cause a different (and harder to track down) bug further down the line in your program.
There can be a valid difference between null and "". A null value usually indicates that no value was set or the value is unknown. An empty string indicates that it was deliberately set to be empty. Depending on your program, that subtle difference could be important.
我不同意其他海报。 使用空字符串是可以接受的。 我更喜欢尽可能使用它。
在大多数情况下,空字符串和空字符串代表完全相同的事物 - 未知数据。 无论用 null 还是空字符串来表示它都是一个选择问题。
I disagree with the other posters. Using the empty string is acceptable. I prefer to use it whenever possible.
In the great majority of cases, a null String and an empty String represent the exact same thing - unknown data. Whether you represent that with a null or an empty String is a matter of choice.
在特定情况下,在将值设置在其他地方之前使用该值是否真的有意义,并且在这种情况下表现为空字符串? ie 是一个空字符串,实际上是一个正确的默认值,并且具有默认值是否有意义?
如果答案是肯定的,那么在声明中将其设置为“”是正确的做法。 如果不是,这将导致错误更难发现和诊断。
Does it actually make sense in a specific case for the value to be used before it is set somewhere else, and to behave as an empty String in that case? i.e. is an empty string actually a correct default value, and does it make sense to have a default value at all?
If the answer is yes, setting it to "" in the declaration is the right thing to do. If not, it's a recipe for making bugs harder to find and diagnose.
决不。 你为什么要这么做? 这会给出不正确的结果。 null 和“””不一样。
No way. Why do you want to do that? That will give incorrect results. nulls and """ are not same.