我使用x!=null以避免NullPointerException。还有其他选择吗?
if (x != null) {
// ...
}
我使用x!=null以避免NullPointerException。还有其他选择吗?
if (x != null) {
// ...
}
当前回答
好的,我现在已经从技术上回答了一百万次,但我不得不这么说,因为这是一场与Java程序员的无休止的讨论。
很抱歉,我不同意以上所有内容。我们必须在Java中测试null的原因是,Java程序员一定不知道如何处理内存。
我这么说是因为我有很长的C++编程经验,而我们不这么做。换句话说,你不需要这样做。注意,在Java中,如果你命中了一个悬空指针,你会得到一个正常的异常;在C++中,此异常通常不会被捕获并终止程序。
不想这样做吗?然后遵循C/C++中的一些简单规则。
不要轻易实例化事物,认为每一个“新”都会给你带来很多麻烦,并遵循这些简单的规则。
一个类只能通过3种方式访问内存->
它可以“拥有”类成员,他们将遵循以下规则:所有“HAS”成员都是在构造函数中“新建”的。您将在析构函数或等效的close()中关闭/取消分配同一类的Java函数,而不是其他类。
这意味着您需要记住(就像Java一样)谁是每个资源的所有者或父级,并尊重该所有权。对象只能由创建它的类删除。此外->
一些成员将被“使用”,但不拥有或“拥有”。这是另一个类中的“OWN”,并作为参数传递给构造函数。由于这些是由另一个类拥有的,我们永远不会删除或关闭它,只有父类才能删除或关闭。类中的方法还可以实例化本地对象供内部使用,这些对象永远不会传递到类的外部,或者它们应该是正常的“有”对象。
最后,要使所有这些工作正常进行,您需要有一个严格的设计,以层次结构形式使用类,并且不进行循环。
在这种设计下,遵循上述规则,层次结构设计中的子类不可能访问被破坏的指针,因为这意味着父类在子类之前被破坏,而层次结构非循环设计不允许这样做。
最后,还要记住,在启动系统时,应该从上到下构建层次结构,并从下到上销毁。任何地方都不会有空指针,或者有人违反了规则。
其他回答
如果您使用的是java8或更高版本,请从java.util.Objects获取isNull(yourObject)。
示例:-
String myObject = null;
Objects.isNull(myObject); //will return true
用法:以下代码返回非空值(如果名称不为空,则返回该值,否则返回默认值)。
final String name = "Jobin";
String nonNullValue = Optional.ofNullable(name).orElse("DefaultName");
如果不允许空值
如果从外部调用方法,请从以下内容开始:
public void method(Object object) {
if (object == null) {
throw new IllegalArgumentException("...");
}
然后,在该方法的其余部分中,您将知道该对象不为空。
如果它是一个内部方法(不是API的一部分),只需记录它不能为空,就可以了。
例子:
public String getFirst3Chars(String text) {
return text.subString(0, 3);
}
但是,如果您的方法只是传递值,而下一个方法传递值等,则可能会出现问题。在这种情况下,您可能需要检查上述参数。
如果允许为空
这真的取决于。如果发现我经常这样做:
if (object == null) {
// something
} else {
// something else
}
所以我分支,做两件完全不同的事情。没有难看的代码片段,因为我确实需要根据数据做两件不同的事情。例如,我应该处理输入,还是应该计算一个好的默认值?
实际上,我很少使用“if(object!=null&&…”这个成语。
如果你展示了你通常使用这个习语的例子,那么给你举例可能会更容易。
在我看来,这似乎是初级到中级开发人员在某个时候往往会面临的一个相当普遍的问题:他们要么不知道,要么不信任他们正在参与的合同,并防御性地过度检查空值。此外,在编写自己的代码时,他们倾向于依赖于返回null来指示某些内容,从而要求调用者检查null。
换言之,有两种情况会出现空检查:
在合同条款中,null为有效响应;和如果它不是有效的响应。
(2) 很容易。从Java1.7开始,您可以使用Objects.requireOnNull(foo)
该方法的“正确”用法如下。该方法返回传递给它的对象,如果对象为空,则抛出NullPointerException。这意味着返回的值总是非空的。该方法主要用于验证参数。
public Foo(Bar bar) {
this.bar = Objects.requireNonNull(bar);
}
它也可以像断言一样使用,因为如果对象为空,它会抛出异常。在这两种情况下,都可以添加一条消息,该消息将显示在异常中。下面将其用作断言并提供消息。
Objects.requireNonNull(someobject, "if someobject is null then something is wrong");
someobject.doCalc();
当值为null但不应为null时,通常会引发特定异常(如NullPointerException),这有利于引发更一般的异常(如AssertionError)。这是Java库采用的方法;当参数不允许为null时,支持NullPointerException而不是IllegalArgumentException。
(1) 有点难。如果你无法控制正在调用的代码,那么你就被卡住了。如果null是有效的响应,则必须检查它。
然而,如果是由你控制的代码(通常是这样),那就另当别论了。避免使用null作为响应。对于返回集合的方法,很容易:总是返回空集合(或数组)而不是空值。
对于非集合,这可能会更困难。举个例子:如果您有这些接口:
public interface Action {
void doSomething();
}
public interface Parser {
Action findAction(String userInput);
}
其中Parser接收原始用户输入并找到要做的事情,如果您正在实现某个命令行接口。现在,如果没有适当的操作,您可能会使契约返回null。这导致了你所说的空值检查。
另一种解决方案是从不返回null,而是使用空对象模式:
public class MyParser implements Parser {
private static Action DO_NOTHING = new Action() {
public void doSomething() { /* do nothing */ }
};
public Action findAction(String userInput) {
// ...
if ( /* we can't find any actions */ ) {
return DO_NOTHING;
}
}
}
比较:
Parser parser = ParserFactory.getParser();
if (parser == null) {
// now what?
// this would be an example of where null isn't (or shouldn't be) a valid response
}
Action action = parser.findAction(someInput);
if (action == null) {
// do nothing
} else {
action.doSomething();
}
to
ParserFactory.getParser().findAction(someInput).doSomething();
这是一个更好的设计,因为它导致了更简洁的代码。
也就是说,findAction()方法抛出带有有意义的错误消息的异常可能是完全合适的——尤其是在这种情况下,您依赖于用户输入。findAction方法抛出一个异常比调用方法用简单的NullPointerException(没有解释)爆炸要好得多。
try {
ParserFactory.getParser().findAction(someInput).doSomething();
} catch(ActionNotFoundException anfe) {
userConsole.err(anfe.getMessage());
}
或者,如果您认为try/catch机制太难看,而不是Do Nothing,那么您的默认操作应该向用户提供反馈。
public Action findAction(final String userInput) {
/* Code to return requested Action if found */
return new Action() {
public void doSomething() {
userConsole.err("Action not found: " + userInput);
}
}
}
Java中常见的“问题”确实存在。
首先,我的想法是:
我认为,当传递NULL时,如果NULL不是有效值,“吃掉”某些东西是不好的。如果您退出方法时没有出现某种错误,那么这意味着您的方法中没有任何错误,这是不正确的。在这种情况下,您可能会返回null,在接收方法中,您再次检查null,并且它永远不会结束,结果是“if!=null”等。。
因此,IMHO,null必须是阻止进一步执行的关键错误(即,null不是有效值)。
我解决这个问题的方法是:
首先,我遵循以下惯例:
所有公共方法/API始终检查其参数是否为空所有私有方法都不检查null,因为它们是受控制的方法(如果上面没有处理null指针异常,就让它终止)唯一不检查null的其他方法是实用程序方法。他们是公开的,但如果你出于某种原因打电话给他们,你知道你通过了哪些参数。这就像试图在水壶里烧水而不提供水。。。
最后,在代码中,public方法的第一行如下所示:
ValidationUtils.getNullValidator().addParam(plans, "plans").addParam(persons, "persons").validate();
注意,addParam()返回self,这样您就可以添加更多的参数来检查。
如果任何参数为空,方法validate()将抛出checked ValidationException(checked或unchecked更多是设计/品味问题,但我的ValidationException已选中)。
void validate() throws ValidationException;
例如,如果“计划”为空,则消息将包含以下文本:
“参数[plans]遇到非法参数值null”
正如您所看到的,用户消息需要addParam()方法中的第二个值(字符串),因为即使有反射(无论如何都不是本文的主题…),也无法轻松检测传入的变量名。
是的,我们知道,在这一行之外,我们将不再遇到空值,因此我们只需安全地调用这些对象上的方法。
这样,代码就干净、易于维护和可读。
有时,您可以使用对其参数进行操作的方法来定义对称操作:
a.f(b); <-> b.f(a);
如果你知道b永远不可能为空,你可以交换它。它对equals最有用:而不是foo.equals(“bar”);最好使用“bar”。equals(foo);。