为什么Java中的自动装箱允许我为布尔值提供3个可能的值? [英] Why does autoboxing in Java allow me to have 3 possible values for a boolean?

查看:144
本文介绍了为什么Java中的自动装箱允许我为布尔值提供3个可能的值?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

参考: http://java.sun。 com / j2se / 1.5.0 / docs / guide / language / autoboxing.html


如果您的程序试图自动启动null,它将抛出NullPointerException。

"If your program tries to autounbox null, it will throw a NullPointerException."

如果尝试将null赋给布尔值,javac会给你一个编译时错误。说得通。尽管如此,将null赋值给布尔值也是如此。我猜也是有道理的。

javac will give you a compile-time error if you try to assign null to a boolean. makes sense. assigning null to a Boolean is a-ok though. also makes sense, i guess.

但是让我们考虑一下你在尝试autounbox null时会得到一个NPE的事实。这意味着你不能在没有空值检查或异常处理的情况下安全地对布尔值执行布尔运算。在整数上进行数学运算也是如此。

but let's think about the fact that you'll get a NPE when trying to autounbox null. what this means is that you can't safely perform boolean operations on Booleans without null-checking or exception handling. same goes for doing math operations on an Integer.

很长一段时间,我是java1.5 +中自动装箱的粉丝,因为我认为它让java更接近于真正面向对象。但是,昨晚遇到这个问题之后,我得说我认为这很糟糕。当我尝试使用未初始化的原语时,编译器给我一个错误是一件好事。如果我输了,我不想使用自动装箱。

for a long time, i was a fan of autoboxing in java1.5+ because I thought it got java closer to be truly object-oriented. but, after running into this problem last night, i gotta say that i think this sucks. the compiler giving me an error when I'm trying to do stuff with an uninitialized primitive is a good thing. I dont want to use autoboxing if I lose that.

我想我可能误解了自动装箱的问题,但与此同时我永远不会接受布尔值应该能够有3个值。谁有人解释这个?我得到的是什么?

I think I may be misunderstanding the point of autoboxing, but at the same time I will never accept that a boolean should be able to have 3 values. can anyone explain this? what am i not getting?

推荐答案

盒装类型是引用类型,所有引用类型,原始框是否可以引用。这就是 Boolean 可以引用 null 的原因。那么整数也可以。那么 String 等等。

Boxed types are reference types, and all reference types, primitive boxes or not, can refer to null. That's why a Boolean can refer to null. So can an Integer. So can a String, etc.

盒装类型不是为了使Java真正面向对象而设计的。 Java 永远不会是一种纯粹的面向对象的语言,你不应该像这样编写代码。原始类型永远不会消失,实际上只要有选择就应该是首选。

Boxed types are not designed to make Java truly object oriented. Java will never be a purely object oriented language, and you should not code as if this is the case. Primitive types will never go away, and in fact should be preferred whenever there's a choice.

以下是来自 Effective Java 2nd Edition的引用,第49项:首选原语类型为盒装基元(作者强调):

Here's a quote from Effective Java 2nd Edition, Item 49: Prefer primitive types to boxed primitives (emphasis by author):


总之,只要你拥有了原始元素,就可以优先使用基元。选择。原始类型更简单,更快捷。如果你必须使用盒装基元,小心! Autoboxing降低了使用盒装基元的详细程度,但没有降低危险性。当你的程序将两个盒装基元与 == 运算符进行比较时,它会进行身份比较,几乎可以肯定不是你想要的。当您的程序执行涉及盒装和未装箱原语的混合类型计算时,它会进行拆箱,而当您的程序取消装箱时,它会抛出 NullPointerException 。最后,当您的程序框原始值时,它可能导致代价高昂且不必要的对象创建。

In summary, use primitives in preference to boxed primitive whenever you have the choice. Primitive types are simpler and faster. If you must use boxed primitives, be careful! Autoboxing reduces the verbosity, but not the danger, of using boxed primitives. When your program compares two boxed primitives with the == operator, it does an identity comparison, which is almost certainly not what you want. When your program does mixed-type computations involving boxed and unboxed primitives, it does unboxing, and when your program does unboxing, it can throw NullPointerException. Finally, when your program boxes primitive values, it can result in costly and unnecessary object creations.

这篇关于为什么Java中的自动装箱允许我为布尔值提供3个可能的值?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆