万恶的NPE差点让我半个月工资没了

简介: 万恶的NPE差点让我半个月工资没了

引言

最近看到《阿里巴巴Java开发手册》(公众号回复[开发手册]免费获取)第11条规范写到:

防止 NPE ,是程序员的基本修养

NPE(Null Pointer Exception)一直是开发中最头疼的问题,也是最容易忽视的地方。记得刚开始工作的时候所在的项目组线上出现最多的bug不是逻辑业务bug而是NPE,所以后面项目组出了一个奇葩的规矩,线上如果谁出现一个NPE的问题就罚款100元,用作团建费用。如果项目组每个人一个月都出现个两三个NPE的话。那么项目组是不是每个月都可以去团建下(自己掏钱海吃海喝,心不心疼)。不过自从这个规矩实施以来,线上的NPE就渐渐的少了,从最初的一个月团建一次到最后的半年团建一次。大家写代码都比较谨慎了,只要用到对象或者集合的时候二话不说上来先判空,所以产生的NPE就少了。

业务中返回结果的空值

在我们常见的业务开发中是不是经常会有这样的接口:

package com.workit.demo.nullexcption;

import com.workit.demo.proxy.User;

import java.util.List;

public interface IUserSearchService {
  /**
   * 查询用户列表
   * @return
   */
  List<User> listUser();

}

这个接口是不是存在两个潜在的问题?

  • listUser这个方法 如果没有数据,那它是返回空集合还是null呢?
  • getUserById 如果根据ID没有找到用户,是抛异常还是返回null呢?

首先我们先看下listUser这个方法的实现:

 public List<User> listUser() {
        List<User> userList = userRepository.listUser();
        if (null == userList || userList.size() == 0) {
            return null;
        }
        return userList;
    }

这种实现如果调用者是一个严谨的人或者像我这样被NPE罚款买过单的人,是会对返回结果进行null的判断。如果调用者并非谨慎的人或者刚刚入门的人,他就会按照自己的理解去调用接口,拿到结果就不管三七二十一上来对结果就是一顿循环操作,而不进行是否为null的条件判断,如果这样的话,是非常危险的,它很有可能出现空指针异常!这就是在代码中埋了一个定时炸弹,不知道什么时候就会爆炸。
在这里插入图片描述
由于存在这种不安全的隐患我们可以看下第二种实现:

  public List<User> listUser() {
        List<User> userList = userRepository.listUser();
        if (null == userList || userList.size() == 0) {
            return new ArrayList<>();
        }
        return userList;
    }

对于这种实现它一定会返回List,即使没有数据,也会返回一个空集合。通过以上的修改,我们成功的避免了有可能发生的空指针异常,这样的写法更安全!
那针对于上面的两种实现,一个是需要调用者进行判空,一个是提供接口的人返回默认值。那我们到底应该用哪种方式呢?这种情况《阿里巴巴开发手册》也有明确规定:
在这里插入图片描述所以还是那句话使用任何对象或者集合之前记得先判空

业务中请求参数空值

 /**
   * 根据用户ID查询当前用户
   * @param id
   * @return
   */
  User getUserById(Integer id);

这个接口的描述,你能确定入参id一定是必传的吗? 我觉得答案应该是:不能确定。除非接口的文档注释上加以说明。那么我们应该怎样来约束入参呢?

  • 强制约束
  @Override
    public User getUserById(Integer id) {
        if (Objects.isNull(id)){
            throw new IllegalArgumentException("id不能为空");
        }
        return null;
    }

通过jsr 303进行严格的约束声明配合AOP的操作进行验证。

User getUserById(@NotNull  Integer id);

其他需要注意的NPE

switch中的空指针异常

看下面的列子妥妥的NPE

 public static void main(String[] args) {
        eat(null);
    }
     enum EatType{
         Breakfast,Lunch,Dinner;
    }
    public static void eat(EatType eatType){
        switch(eatType){
            case Breakfast:
                System.out.println("吃早饭");
                break;
            case Lunch:
                System.out.println("吃中饭");
                break;
            case Dinner:
                System.out.println("吃晚饭");
                break;
            default:
                System.out.println("输入错误");
                break;
        }
    }
数据库的sum函数

在这里插入图片描述
如果price对应的所有的值为null,那么算出来的和为null
在这里插入图片描述
如果采用ifnull函数就可以求和就是0这样就可以避免空指针。
在这里插入图片描述

使用Map类集合时需要注意存储值为null的时候

笔者就是由于存储了null值造成生产事故,差点被开除了!详细介绍可以阅读以前文章《Java采坑记》
在这里插入图片描述

使用 java.util.stream.Collectors 类的 toMap()方法注意value为空时

在这里插入图片描述
如果项目里面就是有null值怎么办呢?可以用下面几种方法来解决:

  • 过滤值为null
  • 换一种写法
  • 据说这个问题java9就修复了,所以也可以尝试升级jdk
  List<Pair<String, Double>> pairArrayList = new ArrayList<>(2);
        pairArrayList.add(new Pair<>("version1", 4.22));
        pairArrayList.add(new Pair<>("version2", null));
        // 第一种过滤值为null的
        Map<String, Double> map = pairArrayList.stream().filter(p-> Objects.nonNull(p.getValue())).collect(
                Collectors.toMap(Pair::getKey, Pair::getValue, (v1, v2) -> v2));
        System.out.println(map.toString());
        // 换一种实现方式
        LinkedHashMap<Object, Object> collect = pairArrayList.stream().collect(LinkedHashMap::new, (m, v) -> m.put(v.getKey(), v.getValue()), LinkedHashMap::putAll);
        System.out.println(collect.toString());

输出结果

{version1=4.22}
{version1=4.22, version2=null}

这个方法还有一个坑如果key相同也会抛异常,感兴趣的同学可以动手试试。

使用 Collection 接口任何实现类的 addAll()方法时,都要对输入的集合参数进行NPE 判断。

在这里插入图片描述

三目运算符可能产生NPE

在这里插入图片描述

那么如何有效的避免NPE呢

  • 使用对象或者集合之前记得先判空。
  • 使用JDK一些API的方法记得要点进源码去大概看看,不要随便拿来就用。
  • 单元测试要对空值进行测试,保证程序的健壮性。
  • 合理的使用JDK1.8提供的Optional来避免NPE
  • 提供接口时候需要对非空参数进行说明,并且对非空参数进行校验,不要太相信调用者。
  • 调用接口的时候一定要对接口返回值进行判空,不要太相信接口提供者。(这个肯定会有值的)。
  • 小心使得万年船

结束

  • 由于自己才疏学浅,难免会有纰漏,假如你发现了错误的地方,还望留言给我指出来,我会对其加以修正。
  • 如果你觉得文章还不错,你的转发、分享、赞赏、点赞、留言就是对我最大的鼓励。
  • 感谢您的阅读,十分欢迎并感谢您的关注。
目录
相关文章
|
3月前
1001 害死人不偿命的(3n+1)猜想
1001 害死人不偿命的(3n+1)猜想
22 0
|
3月前
日本某地发生了一件谋杀案,警察通过排查确定杀人凶手必为4个嫌疑犯的一个题目详解(逻辑类型题2)
日本某地发生了一件谋杀案,警察通过排查确定杀人凶手必为4个嫌疑犯的一个题目详解(逻辑类型题2)
56 1
|
10月前
|
算法 程序员 开发工具
|
10月前
|
敏捷开发 canal otter
【周末瞎想】这个需求能不能不做?
【周末瞎想】这个需求能不能不做?
59 0
|
11月前
|
测试技术
害死人不偿命的(3n+1)猜想
害死人不偿命的(3n+1)猜想
|
网络协议 JavaScript 前端开发
面试周连续剧之奇葩遭遇
接着上一篇文章继续聊面试经历,通过前三天的面试经历,梳理总结一下,虽然拿到了三个offer,但是约过的面试还要继续,这是自己的原则,不能随便放别人鸽子,要有面试节操。在分享今天的面试经历的同时,顺便总结一下这几天面试遇到的各种奇葩遭遇,没有别的意思,只是单纯的分享一下,那么马上开启面试周的第四天吧。
113 1
面试周连续剧之奇葩遭遇
|
存储
妈,旧电脑连加法都算错了,我要换新的
妈,旧电脑连加法都算错了,我要换新的
|
测试技术
PAT 1001 害死人不偿命的(3n+1)猜想
对任何一个正整数 n,如果它是偶数,那么把它砍掉一半;如果它是奇数,那么把 (3n+1) 砍掉一半。
83 0
|
算法 NoSQL 安全
血的教训 ,一次订单号重复的事故我差点被开除
曾经有个项目,我们线上出了一次事故,这个事故的表象大体是这样的: 系统出现了两个一模一样的订单号,订单的内容却不是一样的,而且事情发生的不止一次,被老板发现之后,当月绩效被扣光!
血的教训 ,一次订单号重复的事故我差点被开除
|
敏捷开发 人工智能 安全
周末来个王炸!!
为了让学习更有趣,这篇文章我会列出计算机科学理论和一些概念,并且用类比的方式和尽量少的技术术语来为你进行解释。这样做的目的就是为了让你快速了解计算机,查漏补缺。
周末来个王炸!!