Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

关于 if (someobject != null) 的问题

Posted on 09/09/201410/08/2024 by 四火

NPE

以下内容来自于在 StackOverflow 上的有一个有趣的讨论,说的话题很小,就是对于这样的对象为空的检查:

if (someobject != null) {
    someobject.doCalc();
}

为了避免空指针异常,看起来也没什么不妥。不过代码里面一片一片的对象是否为空的判断,实在难看。

对象是否为空的契约

通常我们在定义 API 的时候,是遵循一些规矩的,这些规矩可以叫做规约,比如这样的接口:

public Set<String> getCollections();

通常情况下,或者说没有特殊说明的情况下,返回的 set 是不能为 null 的,如果没有元素,应当是一个 EmptySet 才对。接口上下游都遵守这样的规约了,那么一些防御性代码就可以省掉。所以严格来说,返回是否为空,应当加入到 API 的文档中去,在返回为空时,需要声明其特殊意义。对象为空,经常能够表达特殊含义:

public void updateUser(User user);

比如这样的方法,要更新 user 的信息,user 有一个属性 age,类型 Integer,当它为空的时候,表示忽略该属性,不更新。如果使用原语类型 int 就需要使用某种特殊值了,没有 Integer 来得自然。

其他语言的改进

在 Groovy 中,使用问号这样一个语法糖,使得代码判空的逻辑得到最简化:

def streetName = user?.address?.street

上面的代码中,如果 user 为空,是不会访问它的 address 成员的,如果 address 为空,则是不会访问 street 的。

在 Objective C 中,方法调用变成了消息传递机制,在往 nil 传递消息的时候,除了返回 0 并没有什么副作用发生。关于 “空”,在 Objective C 当中有这样四种:

null

NULL 来自于 C 语言的空指针;nil 是一个指向空的对象;Nil 和 nil 类似,只不过它是一个指向空的类;NSNull 是用来解决集合元素没法放空元素的问题的,它就相当于空元素的一个包装,在集合中表示一个空元素。

Scala 中有一个 Option 抽象类,它是强类型的,即 Option[T],这个类型一旦被定义就不能改变。它下面有两个子类,Some 和 None,None 是一个表示空的单例对象,而 Some 存放的是实际结果:

def show(x: Option[String]) = x match {
  case Some(s) => s
  case None => "?"
}

编译期间发现对象为空的问题

在 JSR 305: Annotations for Software Defect Detection 中,最初来自于 FindBug 和 IntelliJ 的灵感,说白了就是 @NonNull 和 @CheckForNull 这两个注解:

如果有这样的方法定义:

void someMethod(@NotNull someParameter) { }

那么,在调用的时候,这样的代码会直接编译失败的:

someMethod(null);

反之,定义这样的方法:

@Nullable iWantToDestroyEverything() { return null; }

那么这样未经检查的方法调用也会在编译期间失败:

iWantToDestroyEverything().something();

也就是说,在编译时间就找出潜在的 NPE 问题。

对象为空的检查

不需要自己写防御性质的判断语句来处理空对象了。比如 JDK7 的 Objects 对象:

this.child = Objects.requireNonNull(child, "it is empty");

这会在对象不为空时完成赋值语句,对象为空时抛出消息为 “it is empty” 的异常。

Jarkata Commons 的 API 也提供了检查对象是否为空的方法;或者,你可以用 Java 原生的 assert 关键字。

NPE 也受欢迎

比如这样的代码:

public Photo getGirlfriendPhoto() {
    try {
        return appContext.getPhotoDataSource().getPhotoByName(me.getGirlfriend().getName());
    } catch (NullPointerException e) {
        return null;
    }
}

如果要避免 NPE,就可能会写成类似这样的代码:

public Photo getGirlfriendPhoto() {
    if(appContext != null) {
    	if(appContext.getPhotoDataSource() != null) {
    		if(me != null) {
    			if(me.getGirlfriend() != null) {
    				if(me.getGirlfriend().getName() != null){
    					// finally we are arrived
    					return appContext.getPhotoDataSource().getPhotoByName(me.getGirlfriend().getName());
    				}
    			}
    		}
    	}
    }

    return null;
}

原帖中还有对空对象模式的讨论等等,话题虽小,也挺有趣的。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. EasyMock、EasyMock Class Extension 和 PowerMock
  2. 分页的那些事儿
  3. C++学习杂记
  4. 关于接口设计,还有 Fluent Interface,这种有趣的接口设计风格
  5. 如何思考面向对象

1 thought on “关于 if (someobject != null) 的问题”

  1. stormhouse says:
    09/15/2014 at 10:39 PM

    语言提供简单的语法糖,可省去开发者写好多 if 判断或写 try catch,是对我们极大的便利啊。最近看 swift,它提供的“Optional Chaining”,应该是和 Groovy 类似的吧

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Ticket: TRANSACTION 1.922915 BTC. Go to withdrawal >> https://yandex.com/poll/enter/BXidu5Ewa8hnAFoFznqSi9?hs=20bd550f65c6e03103876b28cabc4da6& on 倔强的程序员
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme