毫无疑问，空指针NullpointerException是我们最常遇到异常，没有之一!
　　在刚进入编程职业时，我想，大部分进入的同学肯定会受到前辈们的叮咛：一定要防止空指针，这是个低级错误。你们不是?好吧，反正我是这样～
　　于是乎，在每一个方法中，无论是接收到的参数还是通过其他方法得到的结果，我都会进行空指针判断，诸如：

[HTML] 纯文本查看 复制代码

1  public boolean isValid(String code){
2         if(StringUtils.isBlank(code)){
3             .....
4         }
5         .....
6     }

或者是

[HTML] 纯文本查看 复制代码

public boolean isValid(String code){
        ....
       User user= userManager.find(code);
        if(user==null){
            ....
        }
    }

　　这样并没有错误不是吗?极大程度上可以预防空指针NullpointerException的发生。
　　按照这种方式，疯狂地防止NullpointerException一段时间后，因为业务需要，在已经实现的业务中修改业务逻辑，突然觉得到处都是if防止空指针代码，原本简短的业务逻辑代码隐藏在了这种防止空指针代码中，有点像电视剧放广告：以前是电视剧中插播广告，现在是广告中插播电视剧。
　　总之，自己写的代码都看的有些晕乎乎，但是，这样做是没错，我也很无奈啊!
　　经过一段时间，review别人写的代码以及参考一些框架源码，我开始问自己一个问题：NullpointerException真的一定需要被处理吗?或者说所有的NullpointerException都需要被自己处理吗?
　　答案显然是否定的!
　　就拿上面的代码作为例子，第一种情况，如果code为null，经过判断后返回false，第二种情况，code存在，但是user不存在，同样返回false。
　　这样的逻辑并没有问题对吧，至少对于这个方法并没有问题，除了多了一些判空语句。
　　假设我们去除上面代码中关于code的判空，并且假设find方法中有对code的处理：按code中的“#”split分成数组。
　　那么当code为null传入isValid方法中，因为find方法使用了code的split方法，会报出空指针异常NullpointerException。
　　我们稍微思考下，这里的NullpointerException会给方法调用方带去什么影响：方法调用方将知道code是必选的参数，不能为null。
　　这样，那方法调用方自己控制传入的参数不能为null就好了，或者自己加上try/catch处理，isValid有自己的逻辑需要实现，既然你调用我，那么就需要满足我的要求，而不是我适应方法调用方的需求!
　　可能例子举的有些抽象，我整理下主要思想：
　　对于传入的参数，方法非底层方法，那么只按照自己认定的方式处理。比如我就认为这个参数不为null，并且后续的处理方式有代码必须要求该参数不可为空，如果为null就会抛出NullpointerException，然后只需要按照不为null的方式处理，不会判断是否为null;
　　同样对于传入的参数，如果方法已经是底层的方法，对该参数不会有不为null的要求，那就需要该方法进行相应空指针判断了，因为你需要抛出对应的异常信息;
　　如果是调用其他方法得到的结果，如果一定需要不为null的，那么就需要判空，因为你同样需要抛出对应的异常信息;
　　可以利用爱情公寓中一句经典台词来记忆：跟我赌，不是看你要什么而是看我有什么。
　　放在这，可以改成：有求我，不是看你有什么，而是看我要什么。
　　这样做可以明显减少这些让人不甚厌烦的判空语句，更好的展现实际的业务逻辑，更易进行维护!!!
　　思想一例子：

[HTML] 纯文本查看 复制代码

1   public boolean isValid(String code){
2         String[] arr=code.split("#");
3         ....
4     }

　　思想二例子(底层，mybatis按照code查询user)：

[HTML] 纯文本查看 复制代码

1      if(StringUtils.isBlank(code)){
2             throw new NullPointerException("code不可为空");
3         }
4         User user=userMapper.findByCode(code);
5         ....
6     }

　　毫无疑问，空指针NullpointerException是我们最常遇到异常，没有之一!
　　在刚进入编程职业时，我想，大部分进入的同学肯定会受到前辈们的叮咛：一定要防止空指针，这是个低级错误。你们不是?好吧，反正我是这样～
　　于是乎，在每一个方法中，无论是接收到的参数还是通过其他方法得到的结果，我都会进行空指针判断，诸如：

[HTML] 纯文本查看 复制代码

1  public boolean isValid(String code){
2         if(StringUtils.isBlank(code)){
3             .....
4         }
5         .....
6     }

或者是

[HTML] 纯文本查看 复制代码

public boolean isValid(String code){
        ....
       User user= userManager.find(code);
        if(user==null){
            ....
        }
    }

　　这样并没有错误不是吗?极大程度上可以预防空指针NullpointerException的发生。
　　按照这种方式，疯狂地防止NullpointerException一段时间后，因为业务需要，在已经实现的业务中修改业务逻辑，突然觉得到处都是if防止空指针代码，原本简短的业务逻辑代码隐藏在了这种防止空指针代码中，有点像电视剧放广告：以前是电视剧中插播广告，现在是广告中插播电视剧。
　　总之，自己写的代码都看的有些晕乎乎，但是，这样做是没错，我也很无奈啊!
　　经过一段时间，review别人写的代码以及参考一些框架源码，我开始问自己一个问题：NullpointerException真的一定需要被处理吗?或者说所有的NullpointerException都需要被自己处理吗?
　　答案显然是否定的!
　　就拿上面的代码作为例子，第一种情况，如果code为null，经过判断后返回false，第二种情况，code存在，但是user不存在，同样返回false。
　　这样的逻辑并没有问题对吧，至少对于这个方法并没有问题，除了多了一些判空语句。
　　假设我们去除上面代码中关于code的判空，并且假设find方法中有对code的处理：按code中的“#”split分成数组。
　　那么当code为null传入isValid方法中，因为find方法使用了code的split方法，会报出空指针异常NullpointerException。
　　我们稍微思考下，这里的NullpointerException会给方法调用方带去什么影响：方法调用方将知道code是必选的参数，不能为null。
　　这样，那方法调用方自己控制传入的参数不能为null就好了，或者自己加上try/catch处理，isValid有自己的逻辑需要实现，既然你调用我，那么就需要满足我的要求，而不是我适应方法调用方的需求!
　　可能例子举的有些抽象，我整理下主要思想：
　　对于传入的参数，方法非底层方法，那么只按照自己认定的方式处理。比如我就认为这个参数不为null，并且后续的处理方式有代码必须要求该参数不可为空，如果为null就会抛出NullpointerException，然后只需要按照不为null的方式处理，不会判断是否为null;
　　同样对于传入的参数，如果方法已经是底层的方法，对该参数不会有不为null的要求，那就需要该方法进行相应空指针判断了，因为你需要抛出对应的异常信息;
　　如果是调用其他方法得到的结果，如果一定需要不为null的，那么就需要判空，因为你同样需要抛出对应的异常信息;
　　可以利用爱情公寓中一句经典台词来记忆：跟我赌，不是看你要什么而是看我有什么。
　　放在这，可以改成：有求我，不是看你有什么，而是看我要什么。
　　这样做可以明显减少这些让人不甚厌烦的判空语句，更好的展现实际的业务逻辑，更易进行维护!!!
　　思想一例子：

[HTML] 纯文本查看 复制代码

1   public boolean isValid(String code){
2         String[] arr=code.split("#");
3         ....
4     }

　　思想二例子(底层，mybatis按照code查询user)：

[HTML] 纯文本查看 复制代码

1      if(StringUtils.isBlank(code)){
2             throw new NullPointerException("code不可为空");
3         }
4         User user=userMapper.findByCode(code);
5         ....
6     }