NullpointerException真的一定要被预防？
毫无疑问，空指针NullpointerException是我们最常遇到异常，没有之一！
在刚进入编程职业时，我想，大部分进入的同学肯定会受到前辈们的叮咛：一定要防止空指针，这是个低级错误。你们不是？好吧，反正我是这样～
于是乎，在每一个方法中，无论是接收到的参数还是通过其他方法得到的结果，我都会进行空指针判断，诸如：
1 public boolean isValid(String code){ 2 if(StringUtils.isBlank(code)){ 3 ..... 4 } 5 ..... 6 }
抑或：
1 public boolean isValid(String code){ 2 .... 3 User user= userManager.find(code); 4 if(user==null){ 5 .... 6 } 7 }
这样并没有错误不是吗？极大程度上可以预防空指针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的，那么就需要判空，因为你同样需要抛出对应的异常信息；
可以利用爱情公寓中一句经典台词来记忆：跟我赌，不是看你要什么而是看我有什么。
放在这，可以改成：有求我，不是看你有什么，而是看我要什么。
这样做可以明显减少这些让人不甚厌烦的判空语句，更好的展现实际的业务逻辑，更易进行维护！！！
思想一例子：
1 public boolean isValid(String code){ 2 String[] arr=code.split("#"); 3 .... 4 }
思想二例子（底层，mybatis按照code查询user）：
1 if(StringUtils.isBlank(code)){ 2 throw new NullPointerException("code不可为空"); 3 } 4 User user=userMapper.findByCode(code); 5 .... 6 }
作者： 风语
因水平限制，本人观点难免会有错误疏漏，如发现有什么不妥或者有更好的建议或意见，还请各位不吝赐教！
本文版权归作者所有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出, 如有问题， 可邮件（1475958950@qq.com）咨询。
