java处理空指针的n种实现

在笔者几年的开发经验中，经常看到项目中存在到处空值判断的情况，这些判断，会让人觉得摸不这头绪，它的出现很有可能和当前的业务逻辑并没有关系。但它会让你很头疼。

有时候，更可怕的是系统因为这些空值的情况，会抛出空指针异常，导致业务系统发生问题。

此篇文章，我总结了几种关于空值的处理手法，希望对读者有帮助。

场景

存在一个 UserSearchService 用来提供用户查询的功能:

publicinterfaceUserSearchService{

List<User> listUser();

Userget(Integer id);

} 

 ​​​​​​​

问题现场

对于面向对象语言来讲，抽象层级特别的重要。尤其是对接口的抽象，它在设计和开发中占很大的比重，我们在开发时希望尽量面向接口编程。
对于以上描述的接口方法来看，大概可以推断出可能它包含了以下两个含义:

1. listUser(): 查询用户列表

2. get(Integer id): 查询单个用户

在所有的开发中，XP 推崇的 TDD 模式可以很好的引导我们对接口的定义，所以我们将 TDD 作为开发代码的” 推动者”。
对于以上的接口，当我们使用 TDD 进行测试用例先行时，发现了潜在的问题：

1. listUser() 如果没有数据，那它是返回空集合还是 null 呢？

2. get(Integer id) 如果没有这个对象，是抛异常还是返回 null 呢？

深入 listUser 研究

我们先来讨论

1. listUser()

这个接口，我经常看到如下实现:

1. publicList<User> listUser(){

2. List<User> userList = userListRepostity.selectByExample(newUserExample());

3. if(CollectionUtils.isEmpty(userList)){//spring util工具类

4. returnnull;

5. }

6. return userList;

7. }

这段代码返回是 null, 从我多年的开发经验来讲，对于集合这样返回值，最好不要返回 null，因为如果返回了 null，会给调用者带来很多麻烦。你将会把这种调用风险交给调用者来控制。
如果调用者是一个谨慎的人，他会进行是否为 null 的条件判断。如果他并非谨慎，或者他是一个面向接口编程的狂热分子 (当然，面向接口编程是正确的方向)，他会按照自己的理解去调用接口，而不进行是否为 null 的条件判断，如果这样的话，是非常危险的，它很有可能出现空指针异常！
根据墨菲定律来判断: “很有可能出现的问题，在将来一定会出现!”

基于此，我们将它进行优化:

1. publicList<User> listUser(){

2. List<User> userList = userListRepostity.selectByExample(newUserExample());

3. if(CollectionUtils.isEmpty(userList)){

4. returnLists.newArrayList();//guava类库提供的方式

5. }

6. return userList;

7. }

对于接口 (List listUser())，它一定会返回 List，即使没有数据，它仍然会返回 List（集合中没有任何元素）;
通过以上的修改，我们成功的避免了有可能发生的空指针异常，这样的写法更安全！

深入研究 get 方法

对于接口

1. Userget(Integer id)

你能看到的现象是，我给出 id，它一定会给我返回 User. 但事实真的很有可能不是这样的。

我看到过的实现:

1. publicUserget(Integer id){

2. return userRepository.selectByPrimaryKey(id);//从数据库